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Introduction 


H P-UX system patching is one of the most confusing areas for new 
system administrators. Patching has its own terminoiogy and toois, and 
patch management has its own motivations and methods. Whiie some 
patch documentation exists, it is found piecemeai in separate manuais. 
Thistutoriai summarizes the technicai information required to 
understand HP-UX patching. 

Piease send your questions and comments topatchguide@hp.com. if 
appropriate, inciude page numbers and document revision with your 
comments. 


Typographical 

Conventions 


This guide uses thefoiiowing typographicai conventions: 

Computer Computer font indicates iiterai items dispiayed by the 

computer. For exampie: file not found 

User input Boid, computer text indicates iiterai items that you 
type. For exampie, to change to your account's home 
directory, enter: 

cd 

itaiics Manuai tities, variabie in commands and emphasized 

words appear in itaiics. For exampie, you wouid 
substitute an actuai directory name for 
directory_name in this command: 


cd d±rectory_naioe 

[ ] and I Brackets [ ] encioseoptionai items in command 

syntax. The verticai bar | separates syntax items in a 
iist of choices. For exampie, you can enter any of these 
three items in this syntax: 

Is [-a I -i I -x] 

Enter Text in this bold, sans-serif font denotes keyboard keys 

and on-screen menu items. A notation of Ctrl-Q 
indicates that you shouid hoid the Ctrl key down and 
press Q. 
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Introduction 


The following chapters in this document cover the steps required to 
create and use patch depots. The appendices provide supporting 
information. 

• Chapter 2, "Planning for Recovery." 

Planning for recovery can create a virtual "Undo" button that lets you 
return a system to a previous state. This limits risk and lets you 
support a proactive patching methodology. This chapter discusses the 
basic requirements and options for system recovery. 

• Chapter 3 , "Acquiring Patches." 

You can get patches from a wide variety of sources, each with 
different abilities. Some sources require an H P support contract while 
others are free. This chapter describes the array of patch sources and 
how you can use them to acqui re patches. 

• Chapter 4, "Depot Management." 

The patch depot lets you use patches most efficiently by letting you 
manage systems as groups rather than as individual systems. This 
chapter descri bes the types of patch depots and how to use them. 

• Chapter 5, "Patch I nstallation." 

Once you have created a patch depot, you must install the depot 
contents onto other systems. This chapter descri bes the recommended 
steps to install, configure, and verify patches. 

• Appendix A, "Basic Patch Concepts." 

Patches terminology and operations differ from other types of H P-UX 
software. This appendix provides a basic understanding of patch 
concepts. 

• Appendix B, "SD-UX Tools & Objects." 

All patch operations involve some aspects of the Software Distributor 
(SD) tools. This appendix provides SD information related only to 
patching. 

• Appendix C ,'The Patch Text File." 

The patch text file provides the core documentation of each patch. 
This appendix lists and describes all of the fields within the .text 
file. 
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Introduction 

Getting Help 


Getting Help 

For technical support, software management, and electronic patch 
management services, contact HP's IT Resource Center (ITRC): 

http://itrc.hp.com 

Use the ITRC to: 

• Quickly access customized support tools 

• Make informed decisions with proactive information 

• Access a rich knowledge database to quickly self-sol ve problems 

• Submit hardware and software calls online 

• I dentify and download patches quickly and accurately 

• Get one-stop access to software updates for your entitlements 

• Take advantage of ITRC resources across the IT life-cycle: 

— Forums—a community where you can collaborate and tackle IT 
questions with peers 

— Training—including online seminars and self-paced web-based 
training 

— Planning, Design and I mplementation—guidance to manage 
changes to your IT environment 


Chapter 1 


13 






Introduction 

Other Sources of Information 


Other Sources of I nformation 

HP-UX Technical Documentation 

All H P-UX technical documentation is available at: 
http://docs.hp.com 

This source provides online access to HP-UX manuals, guides, and white 
papers. Information on particular hardware platforms, HP-UX releases, 
and software products is available for browsing, download, or purchase. 

H P Software Depot 

http://software.hp.com 

The H P Software Depot provides a variety of HP-UX software. While 
some require purchase, many products (such as Ignite-UX and the 
Support Plus patch bundles) are free. 

Interex 

http://www.interex.org/tech/9000/index.html 

The I nternational Association of Hewlett-Packard Computing 
Professionals, known as I nterex, maintains this list of technical 
resources for H P-UX systems. I nterex, which is not a part of H P, is also 
noted for the yearly trade shows I nterworks and H PWorld trade shows 
and for regional users groups. Review the main page 
(http://www.interex.org) to learn about the benefits of membership. 

HP-UX Administrators Mailing List 

http://www.dutchworks.nl/htbin/hpsysadmin 

Another resource outside of HP istheHP-UX Administrators Mailing 
List. This URL provides an interface to the list archives dating back to 
1995. Tojoin the list itself, send email tomajordomo@dutchworks.nl 
and include the following command in the body of the message: 

subscribe hpux-admin-digest 

See also the Software Archive and Porting Centre for H P-UX at this 
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Other Sources of Information 


URL: 

http://hpux.cs.Utah.edu/ 
or 

http://hpux.cae.wise.edu/ 

Mirrored sites are available for Canada, France, Germany, Italy, Japan, 
Netherlands, South Africa, and the UK. 

Other Web Resources 

Additional help with HP-UX patching and related resources is available 
on the Web: 

• Support Plus information: 

http://software.hp.com/SUPPORT_PLUS/ 

• Latest hardware support tools (diagnostics) information, including 
STM and E M S H ardware M onitors: 

http://docs.hp.com/hpux/diag/ 

• Latest H P-UX 10.20 manuals and white papers: 
http://docs.hp.com/hpux/os/10.x/ 

• HP-UX Hi features and news: 

http://www.hp.com/productsl/unix/operating/ 

• Latest Ignite-UX information: 

http://software.hp.com/products/IUX/ 

• Software Distributor (SD): 

http://software.hp.com/SD_AT_HP/ 

• European information: 
http://itre.hp.com/ 

Select the link to the European site. 
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Planning for Recovery 


Recovery Planning 
and Patching 


This chapter presents an overview of planning for system recovery. 

• Establish a recovery plan and do all necessary pre-work. This 
includes setting up the root volume group, selecting a recovery 
technique, planning for system re-installation, and keeping a "wish 
list" of changes you want to make to a system when it is down. 

• Use more than one recovery option to protect yourself from events 
such as a bad tapes or network failures. 

• Proactive maintenance—fixing known problems beforethey appear 
on a system—can reduce the cost of a system fai I ure. 

• Use patches as a form of proactive maintenance. The documentation 
for each patch lists all of the defects or enhancements that the patch 
addresses. You can weigh the known cost of returning to an original 
system state against the documented conditions of a patch. 
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The Root Volume Group 

The Logical Volume Manager (LVM) lets you subdivide a single disk or 
treat a group of disks as a single unit. To enable the recovery options 
discussed in thischapter, you must properly set up the volume group 
that contains the core system (also known as the root volume group, 
usually named vgoo). 

These concepts also apply to users of whole-disk HFS root disks. 

A volume group is a group of one or more physical volumes or disks. The 
physical volumes in a volume group form a pool of disk space which may 
beallocated to one or more logical volumes. Volume groups usually follow 
the naming convention: 

• /dev/vgOO 

• /dev/vgOl 

• /dev/vg02, and so on. 


However, you may use any naming convention you wish. By default, vgOO 
is a special volume group known as the "root volume group" which typi¬ 
cally contains the default boot disk and the majority of the H P-UX oper¬ 
ating system. You may have other volume groups on your system for 
applications, and other user and application data. 

Separating Volatile Data from Stable System Data 

You can preserve a known system state by creating an image of the root 
volume group. You can then return to that image after a failure. 

To preserve the root volume group as a whole, you must place some 
restrictions on the root volume group: 

• Limit the size of the root volume group 

— Reduces the size of recovery i mages 

— Reduces the cost of disk mirroring 

• Do not place volatile data on the root volume group 

— Avoids loss of data when you restore the root volume image 
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Planning for Recovery 

The Root Volume Group 


— Saves an additional recovery step 

• Keep all system data within the root volume group 

— Avoids unexpected recovery problems. For example, Ignite-UX 
may not be able to save critical data if you have relocated parts of 
the directory structure. 

See also "File System Guidelines" on page 20 for more information 


TIP Do not break these rules of data separation except to meet a specific 

need. If you do break these rules, make sure you have some kind of 
alternate recovery methods. 


Preserving Configuration via NIS or DHCP 

Network I nformation Services (NIS) and Dynamic Flost Configuration 
Protocol (DFICP) let you maintain data off of your system. This 
off-system storage of system information that changes frequently (such 
as networking configuration and password files) can simplify the 
restoration process. 

An NIS master server holds master copies of the configuration files, or 
maps. The master server may distribute copies of the maps to NIS slave 
servers to provide load balancing and reliability. An NIS client gets 
configuration information from the master server or a slave server 
instead of from its local configuration files. NIS allows centralized 
management of common configuration files, like /etc/passwd, 
/etc/hosts, and /etc/services. 

• For more information on NFS, see I nstalling and Administering NFS 
Services 

• For more information on DFICP, seethe Ignite-UX Administration 
Guide and I nstalling and Administering I nternet Services. 

These and related documents are available on http://docs.hp.com/ 
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Planning for Recovery 

The Root Volume Group 

File System Guidelines 

To best support recovery, use these guidelines toorganize your file 
system: 

• /, /sbin, /stand, /dev, and /etc 

These directories contain the critical parts of the core system 
required for booting. They must exist completely within the root 
volume group. 

• /usr 

The /usr directory tree contains those elements of the core system 
that support the post-boot system functionality. Although you don't 
need to include this directory with the root volume group, do not place 
it in a volume group that includes volatile data. (Notethat Ignite-UX 
preserves the ful I contents of the vol ume group that i ncl udes the /usr 
directories.) 

• /opt and /var 

Only certain parts of /opt and /var (such as /var/adm/sw) are 
considered part of the core system. (Ignite-UX preserves these areas 
regardless of the parent volume group.) 

• /home 

This directory, which normally holds the login or home directory for 
each user, also holds dynamic user data. You should isolate this 
directory from both the root volume group and /usr. (You can do this 
with NIS and the NFS automounter.) 

• Backup and recovery tools 

If you need to restore additional data from backup media, you can 
save time by including all of the backup and recovery software (such 
as Omni back) within the recovery image. 
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Ignite-UX 


Ignite-UX 

H P's I gnite-UX is a set of tools for system installation, recovery, and 
duplication. Ignite-UX is availablefreeof charge. Todownload the latest 
version and to browse I gnite-UX documentation, go to 
http://software.hp.com/products/IUX 

The Ignite-UX Administration Guide provides complete information 
about using Ignite-UX. 

• Chapter 2 tells you how to install and administer an Ignite-UX 
server. 

• Chapter 3 tells you how to use configuration files to set up system 
recovery information. 

• Chapter 11 tells you how to use the I gnite-UX system recovery tools, 
including: 

— make_tape_recovery(lM) 

— make_net_recovay(4) 

— Expert (manual) recovery procedure using Core media tools 

The Ignite-UX Administration Guide is also available on the I nstant 
Information CD and at http://docs.hp.com 


Chapter 2 


21 





Planning for Recovery 

Have a Wish List 


Have a Wish List 

When you are forced to perform a system recovery, you may want to use 
the opportunity to make some system changes that you can't make at 
any other time. Keep a "wish list "of desired changes so you can take 
advantage of a failure. For example: 

• File System Layout 

If your recovery method requires you to recreate the root volume 
group, use the opportunity to change the number and size of logical 
volumes. For example, you may want to adjust partitions if any 
filesystems such as /var are too small. 

• Hardware Modifications 

Ti me wi 11 11 mit the extent of the hardware changes you can make 
during a system outage, you can accomplish some performance 
optimizations—such as adding another SCSI controller or replacing 
an older root disk with a larger, faster model—at a relatively small 
incremental cost. 

To identify performance bottlenecks caused by slow hardware, use 
performance tools such as H P's GlancePlus. For more information, 
see the H P Software Depot (http;//5oftware.hpxom) and H P 
OpenView (http;//openview.hpxorn/product£iO- 

• Kernel Tuning 

Consider tuning any kernel parameters that you can alter only by 
reboot! ng the system. H P's GlancePlus can help identify 
opportunities for kernel tuning. 
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Acquiring Patches 


These are the primary sources for acquiring patches from HP: 

• The patch database from the IT Resource Center (ITRC) (page 24). 

• HP patch bundles from Support Plus media or Software Depot 
(page 31) 

• Custom selection from the ITRC (page 35) 

• The ITRC Patch Fulfillment Server (FFS) (page 45) 

About the HP ITRC H P's ITRC is a web-based support environment. Some services are 

available at no cost, others are available only if you have an H P support 
agreement. 

To sign up to usethe ITRC: 

1. Go to the ITRC web site at: 
http://itrc.hp.com 

2. Click on the register now! link. 

3. (Optional) For those with the higher levels of system support, H P 
provides proactive patch analysis in which H P monitors and selects 
the correct patches for your systems. To sign up for additional 
services: 

a. Click on the my profile link. 

b. Click on the link a support agreement to your user id link. 

c. Followthescreen instructions. 

Please consult your local HP sales representative for more information 
about additional services. 
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Using the Patch Database 

Use the patch database as your primary mechanism for searching for 
and acquiring individual patches. To access the database: 

1. Go to the ITRC web site: http://itrc.hp.com 

2. Click on the log in link. The log-in screen appears. 

3. E nter your user name and password. 

4. Click on the log-in link. The main ITRC page appears. 

5. Click on the maintenance and support link. 

6. Click on the individual patches link in the patching section. The patch 
database main page appears (Figure 3-1). 

7. Click on the hp-ux link. The patch database search page appears 
(Figure 3-2). 

This document discusses two ways of findi ng FI P-U X patches from the 
search page: 

• Searching by keyword 

• E nteri ng specific patch names 
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Figure 3-1 Patch Database Main Screen 
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Searching for HP-UX Patches by Keywords 

To conduct a keyword search: 

1. Select the hardware by clicking on a radio button (for example, Series 
700). 

2. Select an OS from the pop-up menu (for example, 10.20). 

3. Select Search by Keyword from the pop-up menu. 

4. E nter one or more keywords I n the text field. 
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Acquiring Patches 

Using the Patch Database 


5. Select a search criteria: 

• all words 

• any word 

• exact phrase 

• boolean 

— BcxDlean search results are limited to 200 results. 

— The precedence of boolean operators in a search are: 

a. Expressions inside parentheses () 

b. NOT, AND 

c. OR 

— Expressions are processed from I eft to right. Expressions inside 
parentheses are evaluated following the same order of 
precedence. 

— An all UPPERCASE or all lowercase search string yields a 
case- i nsen si t i ve sea rch. 

— A mixed case search string yields a case-sensitive search. 

6. Click SEARCH. 

Figure 3-3 shows the results of a keyword search on "LVM " and 
"mirrored." Listed are the patch name, size in bytes, and a one line 
description of each patch. Each patch name is a clickable hyperlink to 
the patch text file, which documents the patch. (See Appendix C , 'The 
Patch Text File.") 
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Figure 3-2 


Figure 3-3 
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Figure 3-4 
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Welcome, demo handlel 
(ESCDEMO) 


Acquiring Patches 

Using the Patch Database 


To download a patch from the search results: 

1. Click on the check box next to the patch to select it. (You can also use 
the Select All or Deselect All buttons. 

2. Click Add to Selected Patch List when you have made all your 
selections. A list of all your selected patches appears along with any 
dependent patches (Figure 3-4). See "Dependency Analysis and the 
Patch Database" on page 30. 

List of selected patches and dependencies 

patch database 


Your currently selected configuration is an s700 system running HP-UX version 

10 , 20 , 

NOTE : Read about the HP-UX 10,20 and 11.00 Kernel Patch Process Change 


patch name 


size date 
(kb) posted 


description 


s700 10.20 

PHKL_16750 3392 38/10/23 SIG IGN/SIGCLD.LVM.JFS.PCI/SCSI 

cumulative patch 


Notes: HP Recommended.Fixes critical 
problem.Reboot required after installation. 


^ REMOVE I -> DOWNLOAD 


The patches in your cart above require the following additionaJ patches: 


patch name description 


_Automatically 

r selected 
dependent 
I patches 


PHCO 8871 


1858 86/11/01 


s700 800 10.20 LVM commands 

cumulative patch 


Notes: HP Recommended.This patch is required by; 
PHKL_16750, 


^ DOWNLOAD 


PHCO 12822 


383 87/10/21 


s700 800 10.20fsck yxIsflMI 

cumulative patch 


Notes:HP Recommended.Fixes critical aroblem.This natch is 


3. Click on the DOWNLOAD button beside each listed patch to save it to 
your system. 
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Searching by Patch IDs 

To search by patch ID from the patch database search screen (F igure 3-2): 

1. Select the hardware by clicking on a radio button (for example, Series 
700). 

2. Select an OS from the pop-up menu (for example, 10.20). 

3. Select Search by Patch IDs from the pop-up menu. 

4. Enter one or more patch ID numbers in the text field. 

5. Click SEARCH. A list of all your selected patches appears along with 
any dependent patches (see "Dependency Analysis and the Patch 
Database"). 

6. Click on the DOWNLOAD button beside each listed patch to save it to 
your system. 
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Dependency Analysis and the Patch Database 

When you select a group of patches, the patch database automatically 
analyzes dependencies and lists any other required patches. (Previously, 
you had to manually check each patch text filefor dependency 
information.) This analysis takes superseding and recalled patches into 
account. 

This automatic dependency analysis does not occur when you search for 
a single patch. (This is because a patch may support more than one 
architecture and H P-UX release.) To find out about dependencies for an 
individual patch: 

1. Display the patch description (Figure 3-5). 

2. Select the dependencies link. 


Figure 3-5 Patch Description 


hp home products & services support solutions I how to buy 



PHSS_21980 patch 
description 


• search 
’ online help 
’ contact hp 


Note: Obtaining software or data from HP’s Patoh Database is governed by the JT 
Resouroe Center Terms of Use . Use of software or data obtained from HP’s Patch 
Database is governed by HP Software License Terms , Piease read them before you 
proceed. 


' IT resource center 
home 
’ my profile 
’ logout 

• maintenance and 
support 

' technical knowledge 
base 

• hot docs 
’ support info by 
product 

’ knowledge trees 
Individual patches 


j|Downloadl this patch. Alternatively, you may retrieve this patch via anonymous iip(1) 

from fto://fto.itro.ho.oom/ho-ux oatohes/s7D0 BOO/II.X/PHSS 21980 using your browser’s 
"Save Link As" (Netscape) or "Save Target As" (MSIE) operation. 

patch files dependencies supersedes size critical symptoms defect description 
installation instructions 

Patch Name: PHSS_21980 

Patch Description: s700_800 1 1.X OpenGL 1.1 Runtime patch 
Creation Date: 00/12/12 


Post Date: 00/12/19 

^ training and education 

’ planning, design, and Hardware Platforms - CS Releases; 
implementation s700: 11.00 11.11 

. . s800: 11.00 11.11 


30 


Chapters 





























Acquiring Patches 

HP Patch Bundles 


HP Patch Bundles 

H P provides pre-packaged bundles of patches designed to be i nstalled as 
a unit. These bundles are subjected to stringent levels of testing to 
assure a high level of reliability and are periodically updated. 

You can obtain HP patch bundles from the H P Software Depot on the 
web or (if included in your support contract) from the quarterly Support 
Plus media. 


Software Depot 

TheHP Software Depot (http://www.software.hp.com) Isan online 
store that provides you with instant access to HP software for free trial 
or purchase. 

Software Depot provides a number of patch products. These patch 
products are generally available at no charge and are found in the 
enhancement releases area of Software Depot. 

(Although you can download the software for free, you may have to 
register with Software Depot first.) 

< Support Plus Bundles 

The patch bundles and diagnostic utilities of the Support Plus CDs 
are also provided for free download from Software Depot. The support 
contract restrictions related to the actual media do not apply to 
electronic access. As an added benefit, the bundles are available 
within Software Depot earlier than on media. 

For more information on Support Plus see"Support Plus Media"on 
page 32 and: 

http://www.software.hp.com/SUPPORT_PLUS 

< Additional Core Enhancements (ACE) 

An ACE bundle is a collection of enhancements to the H P-UX 
Operating System. Each ACE release extends H P-UX to support new 
hardware and software features for H P workstations. ACE software 
also corrects any critical or serious defects discovered since the 
original system release. For more information, see: 

http://www.software.hp.com/ACE 


Chapter 3 


31 





Acquiring Patches 

HP Patch Bundles 


• Hardware Extensions (HWE) 

HWE bundles enabling new hardware or enhance OS performance, 
reliability, or functionality. See: 

http://www.software.hp.com/products/HWE 

• Product Updates 

Some HP-UX products release a new version rather than a patch. 
These can be downloaded from Software Depot. Some products 
available at this time include Ignite-UX and Software Distributor. 

< Specialty Patch Bundles 

Occasionally, special needs dictate the creation of a unique patch 
bundle (for example, Y2K defects or support for the European 
currency). 

Support Plus Media 

HP-UX Support PlusCDsdeliver diagnostics and HP-UX system patches 
to you on a quarterly basis. This patch software enables new hardware 
and fixes known defects. The contents of each Support Plus release is 
freely availablefrom Software Depot (page 31), but physical media is 
only availabletocustomers with an HP-UX Software Support contract. 

Requesting Support Plus CD-ROMs 

H P notifies these customers when each Support Plus release becomes 
available. The notification letter includes a request form for physical 
media. 

Support Plus Patch Bundles 

Support Plusincludes patch bundles that contain the following software: 

• Diagnostics (oniinDiag), including Support Tool Manager (STM) for 
online diagnostics, ODE (off-line diagnostics), EMS hardware 
monitors. Predictive Support, EMS Kernel Resource Monitor, and the 
I nstant Capacity on Demand (iCOD) client product. 

• General Release (GR) patches, including current patches for all Core 
Operating System (OS) software. TheGR bundles have recommended 
H P-UX patches with the highest confidence ratings based on patch 
distribution and age, and successful completion of tests by the H P 
Enterprise Patch Test Center. 
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• Quality Pack (QPK) bundle for workstations, including all 
recommended, stable, and third-party defect-fix patches for selected 
Core OS and other products. 

• Hardwar^critical (HWCR) patches, including hardware enablement 
and critical patches. These patches may match or supersede patches 
found in other HP-UX patch bundles. You should install this bundle 
after other patch bundles (e.g. GR and QPK bundles) and after 
installation of applications (e.g. Networking driver products). 

Use the follow! ngtableto determine which bundleyou need to install. 


If your platform is: 

And you want to: 

You should install: 

Updated: 

HP-UX workstation or 

server 

Update or install all the 
latest diagnostic tools, 
including hardware 
monitors 

Diagnostic bundle; 

OnlineDiag 

Quarterly 

HP-UX workstation 

Install selected defect-hx 
patches for the Core OS, 
HP products, or 
important third party 
applications 

Quality Pack (QPK) bundle: 
700QPK1020 (HP strongly 
recommends that you include the 
latest Quality Pack as part of the OS 
environment for end-user systems.) 

As needed 

HP-UX workstation 

Bring all Core OS 
software to current patch 
level without custom 
patch selection 

General Release (GR) bundle for 
HP-UX workstations; 

XSW700GR1020 

Quarterly 

HP-UX workstation 

Enable Visualize-fx 
graphics hardware and 
update selected HP 
applications for this 
hardware 

Visualize-fx Graphics/Hardware 
Enablement bundle; B6825AA 
(Install this bundle after installing HP 
3D graphics software.) 

As needed 

HP-UX workstation 

Enable and manage 
add-on hardware 
(includes patch to update 
PDC workstation 
hrmware) 

Hardware (HW) enablement bundle 
for HP-UX workstations; 

XSW700HW1020 

Quarterly 

HP-UX server 

Install critical patches or 
enable new add-on 

hardware 

Hardware/Critical (HWCR) bundle: 

XSW800HWCR1020 

Quarterly 
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If your platform is: 

And you want to: 

You should install: 

Updated: 

HP-UX server 

Bring all Core OS 
software to current patch 
level without custom 
patch selection 

General Release (GR) 
bundle for HP-UX servers: 

XSW800GR1020 

Quarterly 


Getting More Information 

For detailed information about Support Plus bundles and installation 
instructions, seethe Support Plus User's Guide You can obtain this 
guide from these sources: 

• The H P documentation web site: 
http://docs.hp.com/hpux/os/10.x/ 

• The H P I nstant I nformation CD 

• The Support Plus CD in the file: 

/cdrom/USRGUIDE.PDF 
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Custom Acquisition and Notification 

The H P ITRC offers custom solutions for getting patches or informing 
you about them: Custom Patch Manager (CPM) and Custom Patch 
Notification. Both services requirethe phonein level of support 
agreement or above and may not be available in all geographic locations. 
(You can also use CPM on a pay-per-use basis. Consult the ITRC for 
details.) 

About CPM 

Custom Patch Manager (CPM) is a tool for selecting and downloading 
patches that are appropriate for a target system. 

Benefits of Custom Patch Manager 

• CPM patches and patch information are updated daily. This lets you 
update the col lection script and perform an analysison a regular 
schedule. For example, you can perform a monthly check for new 
critical patches, which could help identify a system risk before it is 
seen in production machines. 

• Automatic dependency and conflict analysis, which reduces the need 
for lengthy review of the patch documentation. 
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Using CPM 

To access CPM: 

1. Go to the ITRC web site (http://itrc.hp.com) and log in. 

2. Click on the maintenance/support link. This takes you to the 
maintenance and support page. 

3. Click on the customized patch bundles (custom patch manager) link. 
This takes you to the custom patch manager main page (Figure 3-6). 

(If your profile indicates you do not have the appropriate support 
agreement, a pay-per-use notice appears. Click on buy now and fill 
out the payment form to continue.) 


Figure 3-6 Custom Patch Manager Main Screen 


hp home | products & sorvicot \ support j solutions | how to buy 



invent 


custom patch manager 


• search 

- online help 
’ contact hp 

• IT resource center 
home 

• my profile 

• logout 


Custom Patch Manager is a tool for configuration based 
patching of systems, You must download and run a 
collect script to gather information about what patches 
and filesets are installed on your target system or 
depot. 

After you have uploaded the resulting configuration file 
to CPM, you will be able to run a Patch Analysis for that 
system or depot. Custom Patch Manager generates a 
Candidate Patch List from which you may choose the 
patches you would like to install. 


solution information 

-» hp 9000 Superdome 
-» software product 
index 

-» hp-ux support plus 
-> multi-OS foundation 


maintenance and 
support 

’ technical knowledge 
base 

• hot docs 

• support info by 
product 

• knowledge trees 

’ individual patches 

• more... 

• training and education 
- planning, design, and 
implementation 
•forums 


Welcome, demo handlel 
(ESCDEMO) 


Custom Patch Manager will give you the opportunity to 
run an analysis to check for conflicts between the 
patches in your Selected Patch List as well as those 
currently installed on you system. 

When you are satisfied with you patch list, you can 
download a Patch Package to your system. 


to start using cpm. select: 

1. Collect Configurations 

Provide up to date configuration data to CPM 

2. Perform Patch Analysis 

Find the most recent set of patches available for your system or depotto 
select for packaging and download 

3. Custom Patch Notification 

Have HP notify you when new patches applicable to your system are 
available. 

to learn howto use cpm, select: 

Overview 

FAQs 

Detailed Instructions 
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Figure 3-7 


Step 1. Collect Configuration Information 

This step requires that you download the cpm_coiiect. sh script. This 
shell script collects the names and revisions of all the products installed 
on your system. H P recommends that you download the script on a 
regular basis to ensure you have the latest version of the script. 

To use the script: 

1. Click on the Collect Configurations link on the main CPM page. This 
displays the system information collection page. 

2. Follow the instructions in the "collect system configuration" section to 
download and execute the script on the system you want to patch 
(Figure 3-7). The script requires no special privileges and creates a 
data file using the name of the system followed by a . fs suffix. 

3. Follow the instructions in the "upload results to IT resource center" 
section to return the data filetothe ITRC via ftp: 

• The ftp system to use is identified on the same ITRC page used to 
download the collection script. 

• Use your ITRC user name and password to log in. 

• Once connected, placethedata file in the incoming subdirectory 
on the ftp server. (This directory is subject to space limitations.) 

Executing the cpm_collect.sh script 


patchsvr> ./cpm_collect.sh 

Copyright (c) Hewlett-Packard 1995-1998. All Rights Reserved. 
cpin_collect. sh version: A. 03.04 

This script will collect information about filesets and installed 
patches from your system in the file /tmp/patchsvr.fs for 
subsequent transfer to Hewlett-Packard. 

Do you wish to continue, [Y] or N ? y 

removing /tmp/patchsvr.fs 

Creating list of patches in /tmp/patchsvr.fs... 

Creating list of products and filesets in /tmp/patchsvr.fs... 

The file /tmp/patchsvr.fs has been created. 
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Step 2. Perform Patch Analysis 

I n this step, you analyze your system configuration information to 
determine what patches you need. 

1. After you have uploaded the configuration information (Step 1), 
return to the custom patch manager main page. 

2. Click on the Perform Patch Analysis link. This displays a list of the 
current configuration files found within the incoming directory. 

3. Click on the radio button beside the appropriate configuration file in 
the list. 

4. (Optional) Usethesearch and filter options at the bottom of the page 
to reduce the number of patches displayed. Options include: 

• Descriptive search 

• Boolean search 

• Critical patches only 

• Fileset filtering 

• Command patches 

• Kernel patches 

• Network patches 

• Subsystem patches 

Click on the tips for setting filters and searching link for more 
information about using these search options. 

5. Click on the DISPLAY CANDIDATE PATCHES button. This displays the 
candidate patch list (Figure 3-8). 

(The search and filter options appear above list. Using these options 
regenerates the display to show only the patches that match the filter 
or search criteria.) 
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Figure 3-8 Candidate Patch List 


description 


date 

installed 

installed 

recommended 

latest 

s700_800 11,00 restore(lM) fix for 
cross-platform archives 

000322 

PHCO 14413131 

JPHCO 10130131 

JPHCO 18138131 

s700_000 11 

,00 login(l) cumulative patch 



IPHCO 10072121 

IPHCO 10572121 

s700_000 11 

,00 pax(1) cummulative patch 

000322 

PHCO 20077131 

IPHCO 2041R131 

IPHCO 20416131 

s700 000 11 
ACLs 

,00 Enhance fincl( 1) for JFS 

000322 

PHCO 20037171 

JPHCO 20575131 

JPHCO 20575131 

s700_000 11 
patch 

,00 useradd(lM) cumulative 

000322 

PHCO 17440121 

JPHCO 20673131 

JPHCO 20673131 

O 

O 

CO 

1 

o 

o 

,00 patch(l) patch 



JPHCO 20818131 

JPHCO 20818131 


The candidate patch list displays: 


• A brief description of the patch 

• The date it was installed on your system 

• A link to a full description of an installed patch 

• A link to the description of the corresponding HP-recommended 
patch. 

— Always use the recommended patch unless the latest patch 
explicitly fixes a problem on your system. 

— If the recommended column is blank, HP does not havea 
patch that is better than the patch (if any) that is already on 
your system. 

• A link to the description of the corresponding latest patch. This 
patch may have a lower patch rating than the recommended 
patch. 

6. Select one or more patches from the candidate list by clicking on the 
check box next to the patch listing. You can also use the select all 
recommended or select all latest buttons at the bottom of the list. 
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Figure 3-9 
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7. (Optional) Click on the patch name to display detailed information on 
the patch (Figure 3-9). (Click the Add button to add the patch to your 
list and go to the selected patch list.) 


Individual Patch Details 


PHSS_21663 Patch Details 


I Add I PHSS_21663 to the Selected Patch List. 

Description: s700_800 11.00 AudioSubsystem June 2000 Periodic Patch 

Status: General Release 

Patch Rating: 3 

Critical Patch: No 

Reboot Required: No 

Dependencies: No 

Package Size: 911360 bytes 

Predecessors: 

This patch supersedes these patches. 

PHSS 17119PHSS 17979 PHSS 18778 PHSS 21482 

Equivalencies: 

This patch is equivalent to these patches. 


s700,10.01 

PHSS 

21662 

s700,10.10 

PHSS 

21662 

s700,10.20 

PHSS 

21662 

sSOO.lO.Ol 

PHSS 

21662 

sSOO.lO.lO 

PHSS 

21662 

s800,10.20 

PHSS 

21662 


Patch Files: 

This patch replaces these files. 
/usr/share/man/manlm.Z/asecure.Im 
/usr/share/man/manlm.Z/aserver.Im 
/opt/audio/lib/libAlib.1 
/opt/audio/lib/libAlib.2 
/opt/audio/lib/libAt.1 
/opt/audio/lib/libAt.2 
/opt/audio/lib/libAt.3 
/opt/audio/bin/Aserver 
/opt/audio/bin/asecure 

What(l) Output: 

Revision information 


8. Click the ADD TO SELECTED PATCH LIST button to display the selected 
patch list (Figure 3-10). This list includes additional information on 
reboot requirements, dependencies, size, and patch age. 

(To remove a patch from the list, deselect the check box beside the 
patch and click the remove button.) 
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Figure 3-10 Selected Patch List 


□ 

Patch Name 

Reboot 

Required 

Dependencies 

iQiSSI 

Date Posted 

V 

PHCO 18837 

No 

No 

225 

330622 

v 

PHCO 18485 

No 

Yes 

10847 

330324 

V 

PHCO 20330 

No 

No 

317 

331202 

V 

PHCO 20441 

No 

No 

3667 

381122 

V 

PHKl 18872 

Yes 

No 

727 

330623 

V 

PHKL 18913 

Yes 

No 

82 

330622 

V 

PHKLJ9159 

Yes 

Yes 

82 

330713 

V 

PHKL 13166 

Yes 

Yes 

215 

330715 

V 

PHKl 18735 

Yes 

No 

72 

330720 

V 

PHKL 18538 

Yes 

Yes 

164 

830824 

V 

PHKL 13704 

Yes 

Yes 

72 

330307 

V 

PHKL 13721 

Yes 

Yes 

185 

331207 

v 

PHKL 13755 

Yes 

Yes 

205 

330315 


Step 3. Conflict Analysis 

In this step, CPM analyzes the selected patches for conflicts. (This step is 
optional but highly recommended.) 

1. Click on the Analyze button below the selected patch list. This 
examines your list of patches for conflicts and displays the results 
(Figure 3-11). 


Figure 3-11 


Resultsof Analysis of Selected Patch List 


I the Selected Patch List for possible oonfliots, 

Tips on conflict resolution are available. 

Recaiied Patches: PHCO 14D44f lnstalled1Reolacements for PHCO 14044 
(Select one patch from each line of table) 



PHCO 14044f Rl JPHC0_22Q9B(3) J PHCO 220961 31 

PHCO lySSSf lnstaJledtReplacements for PHCO 17556 
(Select one patch from each line of table) 
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2. (Optional) Follow the links from the conflicts display to get more 
information about how to resolve the conflict or to view other patches. 
See "Resolving Patch Conflicts" on page 53 for more information. You 
can add other patches to your list if necessary. 

Step 4. Package and Download Your Patches 

1. After you have selected all patches, click the Package button. This 
generates a script and places it in the outgoing subdirectory for your 
account on one of the FTP servers. (CPM directs you to the 
appropriate server.) The script is a shell script that extract scripts 
and provides instructions for downloading your selected patches. 

2. Follow the instructions delivered with your script to run the script on 
your FIP-UX system. 

The selected patches are transferred individually to your system. One 
of the scripts delivered inthe shell archive is used to place all of these 
patches into a common depot for future installation. 

Custom Patch Notification 

Custom Patch Notification is a an optional feature of Custom Patch 
Manager that provides you with weekly or monthly e-mail notification of 
newly posted patches that apply to your system. (This tool differs from 
the ITRC Support I nformation Digests by using configuration files and 
filters to narrow down the list of patches about which you are notified 
and by customizing the report contents.) To set up Custom Patch 
Notification, select the custom patch notification link from the custom 
patch manager main page (Figure 3-6 on page 36). 


NOTE Custom Patch Notification does not work with depot configuration files. 


Profiles 

Profiles specify the kinds of reports you want to receive. 

• A profile may be based off either a Custom Patch M anager 
configuration file or a platform and OS revision. 

• Select one or more filters for your notification list, such as filtering for 
critical patches, by keywords, or for different patch categories. 
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• You may create up to 10 notification profiles 

• Profile names may only contain alphanumeric characters (a-z, A-Z, 
0-9, and the underscore). The first character of name must be a letter. 

• Profiles are processed weekly or monthly. You receive an e-mail if the 
ITRC has posted new patches that apply to any of your profiles. This 
notification includes applicable patch names and one-line 
descriptions. 

• Toget more information about a new patch, log in to the ITRC, goto 
the Custom Patch Manager main page, and view the full reports on 
the Custom Patch Notification main screen. You have the ability to 
specify which fields are displayed in the report by selecting the Patch 
Report Fields. 

Preferences 

The preference screen lets you verify the e-mail address to which your 

notifications are sent. 

• To modify this address, select the User Info link at the top of the 
screen. 

• You can have only one ITRC e-mail address, so changing it affects all 
e-mails you receive from the ITRC. 

Reports 

You can specify whether you want to receive your reports on a weekly or 

monthly basis. 

• Reports are not cumulative from week to week or month to month. 

• Weekly reports are sent out on Sundays. Monthly reports are 
generated on the last day of each month. 

• You can also specify what patch text fields are displayed when you 
view your on-line report. These fields can be changed and the report 
re-loaded if you want to view the same report with different filters 
set. 

Configuration Files 

• Tousea current configuration file, simply select the radio button next 
to the configuration file on which you want your notifications to be 
based. 
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• You can add new configuration files by downloading the 
cpm_coiiect .sh script and uploading the results as described on 
page 37. 

• You can also specify configuration by platform (e.g., 9000/735, 
9000/855) and OS revision (e.g., B.10.20) for a profile. Usethe 
uname(l) command on your system to determine what values to enter 
in these fields: 

To determine the platform, type: uname -m 

To determine the OS revision, type: uname -r 

(If you go from a configuration based profile to a profile based on 
platform and OS revision, you need to click the Reset button to clear 
the configuration filetableso only the platform and revision fields are 
filled in.) 

Filters 

• Custom Patch Notification can filter patch notification lists based on 
these categories: 

— Critical: Lists all patches tagged as critical bytheHP 
(independent of the actual patch categories listed below) 

— Command 

— Kernel 

— Network 

— Subsystem 

• All HP-UX patches are included in one of the four patch categories 
(Command, Kernel, Network, Subsystem). 

• CPM does not let you deselect all categories. 

• Selecting more than one category acts as a logical OR operation. For 
example, if you pick the Command and Kernel options, you are 
notified of all Command patches or all Kernel patches that fit your 
profile. 

• Selecting a category options and the Critical filter acts as a logical 
AND operator. For example, if you pick the Critical, Kernel and 
Command filters, CPM notifies you of all patches tagged asCritical 
AND all Command patches OR all Kernel patches that fit your 
profile. 
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The Fulfillment Server 

The fulfillment server (FFS) is the patch repository used by the patch 
database. You can use ftp to directly access all patches on the FFS. 

Two FFS systems are currently available: 

• ftp://us-ffs.externai.hp.com (Americas and Asia/Pacific) 

• ftp://europe-ffs.external.hp.com (E urope) 

FIP recommends that you use the other techniques discussed in this 
chapter as your primary patch acquisition method. Flowever, the FFS 
offers these advantages 

• You can access patches from any system that supports the ftp 
command and has direct access to the I nternet. (No web server is 
required, although you can also use FFS via the web.) 

• Access is anonymous. You do not need an ITRC account. 

• Works well for finding and downloading a known patch. 
Disadvantages: 

• Does not work well for finding groups of related patches. 

• The FFS server limits the total number of simultaneous ftp 
connections. 
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Accessing the Fulfillment Server via ftp 

Figure 3-12 shows how to use the /usr/bin/ftp command on an H P-UX 
system to connect totheAmericas/Asia/Pacific FFS system. Notethatthe 
response supplied for the name prompt is anonymous. The password used 
is the user's e-mail address. 

Because the FFS server limits the total number of simultaneous ftp 
connections, direct ftp access has an advantage over web ftp access. You 
can perform multiple downloads without having to re-establish a 
connection each time. 

Figure 3-12 Establishing an anonymous FTP session 


patchsvr(103)-> ftp us-ffs.external.hp.com 
Connected to hpcc933.external.hp.com. 

220 - 

220-Welcome to the HP Electronic Support Center ftp server 

220 - 

220 - 

220-You are user 0, and there is a limit of 200 simultaneous accesses. 

220 - 

220-Log in as user "anonymous" (using your e-mail address as your password) 
220-to retrieve available patches for HP-UX, MPE/iX, and other platforms. 
220 - 

220-If you are a user of other HP ESC services, log in with your 
220-HP ESC User ID and password to deposit or retrieve your files. 

220 - 

220-If you have questions, send email to: 

220 - 

220- support_feedback@us-ffs.external.hp.com 

220- hpcc933 ETP server (Version wu-2.4, HP ASL, w/CNS fixes (277) 

220-Wed Jun 24 18:02:04 PDT 1998) ready. 

Name (us-ffs.external.hp.com:username): anonymous 

331 Guest login ok, send your complete e-mail address as password. 
Password:username@hp.com 

230 Guest login ok, access restrictions apply. 

Remote system type is UNIX. 

Using binary mode to transfer files. 
ftp> 
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Figure 3-13 


Web Access to F F S 

You can also access the FFS from your web browser. Simply enter an ftp 
address as you would a URL (Figure 3-13). For example, entering 
ftp: //us-f f s. external.hp. com I nto your browser creates an 
anonymous ftp connection to the Americas/Asia/Pacific FFS system. 

• Advantage: you can browsethe FFS directories graphically. 

• Disadvantage: FFS limits the total number of simultaneous ftp 
connections, and you web browser must re-establish the connection 
each time you change directories or download files. You may have to 
make several attempts if the server is busy. 


Browser Listing of the Fulfillment Server 
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The FFS Directories 

These are some of the more useful FFS directories for FIP-UX patching: 

• /hp-ux_patches/ARCHITECTURE/OS_RELEASE/ 

(HP-UX patches) 

All active HP-UX patches are grouped by architecture (s700, s800, 
and s700_800) and the version of HP-UX supported (lO.x, ii.x). For 
example, patches for Series 700 workstations on H P-UX 10.20 are 
found in the /hp-ux_patches/s700/io .x subdirectory. Patches 
common to both architectures are found under s700_800. 

• /firmware_patches/hp (Firmware patches for HP Hardware) 

This directory contains patches that supply firmware updates to H P 
hardware. Subdirectories exist for firmware specifically for CPUs, 
Fibre Channel, graphics cards, and I/O cards. 

• /superseded_patches/ (Patches that have been superseded by 
newer patches) 

This directory contains patches that have been replaced by newer 
patches. Use them only if you must revert to an earlier version of a 
patch to resolve a specific problem. 

• /export/patches (data files) 

This directory does not deliver any patches, but provides useful data 
files, including: 

— hp-ux_obs_patch_iist, which contains a full list of every patch 
that has been superseded with the name of the active superseding 
patch. 

— hp-ux_patch_matrix, which lists all patches that address known 
security issues for each release. 

— hp-ux_patch_sums, which contains the checksum foT the .depot 
file of all HP-UX patches. 

Patch directories contain the full shar(l) archive and the patch text file. 
The text file contains the patch location within the FFS hierarchy as the 
Path Name field. See Appendix, "Patch Text File Fields," on page 120 for 
more information on the text file. 
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Downloading the Patch 

• To download by ftp: 

1. (Optional) Enterbi to specify a binary transfer. (Theshar archive 
may deliver 8-bit binary data, but is encoded to contain only 7-bit 
characters. When files of this type are transferred through other 
systems such as personal computers they may be treated as text 
and undergo a translation step.) 

2. Usetheget patch_naine command to download specific files, in 
which patch_name is the file you wish to download. (Usemgetfor 
downloading multiplefiles.) 

• To download by your web browser: 

1. Click on the file you want to download. 

2. Right-click on the patch link and select the appropriate save 
option from the pop-up menu (Save Link As... for Netscape, Copy to 
Folder... for I nternet Explorer). This downloads the shar file of the 
patch to your system or displays a dialog to select a location to 
which to download. 

3. Unpack the shar file by typing sh filename 
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About Patch Recommendations 


The patch database helps you find the "best" patches: the most recently 
released patches having the highest HP rating. HP rates patches with a 
three-point scale: 


Table 3-1 

HP Patch Ratings 

HP rating 

Description 

1 or * 

Functional testing by HP has verified; 

• The patch fixes the problem that it purports to fix 

• No unwanted side effects exist 

• The patch will install and de-install in its target environments 

2 or ** 

Patch has been installed in customer environments with no 
problems reported 

3 or *** 

Patch has been stress- and performance-tested by HP in simulated 
customer mission-critical environments using common application 
stacks. (Not all patches receive this testing.) 

R 

Patch is known to introduce another problem and has 
been recalled. It is no longer recommended by HP. (Not 
every recalled patch causes problems for every customer. 
Read the patch description to determine why it was 
recalled.) 

Whenever you download a patch from the patch database, the 

ITRC automatically registers the patch with your account. If any 
of your registered patches is recalled, the ITRC notifies you. 


• The higher the rating, the lower the risk of side-effects and the more 
suitable the patch is for mission critical environments. 

• HP releases a patch after it meets HP's minimum patch quality 
standards. 

• Patches are assigned a rating of 1 upon initial release. The patches 
then receive additional HP and customer environment testing. The 
patch rating is updated accordingly as H P's confidence in the patch 
increases. 
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• When a patch is rated 1, H P recommends that you defer fixing the 
problem until more is known about the patch unless the patch fixes a 
problem critical to your system. 

• Patches undergo testing for promotion to an H P rating of 3 on a 
quarterly basis (on February 1, May 1, August 1, and November 1). If 
you defer installing a patch because it is "Not yet H P Recommended," 
re-check it after one of the quarterly dates. 

• The Rating of a patch may be updated from 1 to 2 on a daily basis. 
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About Patch Notes 

Patches may include descriptive notes to help you determine the status 
or risk of a patch, and any impact to your environment. These are 
displayed in the Notes section of patch lists. Most notes are 
self-explanatory (such as, "Fixes critical problem"or "Reboot required 
after installation"). Other notes include: 

• N ot yet H P recommended 

All patches adhere to certain HP quality standards. Patches are 
assigned an H P Rating of 1, 2, or 3 based on how many quality 
standards they meet. As a matter of course, it purposely takes time to 
meet the higher standards. Upon their initial release, patches are 
assigned an H P Rating of 1 and are labeled "Not yet H P 
Recommended". These patches may fix the problem, but also may 
contain some element of risk. As patches advance on the patch 
confidence scale, the higher the rating becomes. Patches with ratings 
of 2 or 3 are denoted by the term "H P Recommended" in the Notes 
field. 

These patches are avail able to give you the option of obtaining a fix 
sooner if you can tolerate some risk to fix a critical problem. 
Whenever the patch database suggests a patch that is not yet 
recommended by H P, you must make an informed assessment of 
these trade-offs based on your own situation. 

If you are not facing a critical problem, HP recommends waiting for a 
patch to gain a higher HP Rating. 

• Recalled 

A patch may be labeled as recalled when it is known to introduce 
another problem. However, not every recalled patch causes problems 
for every customer. Click on the one line patch description to view the 
patch details to determine why it was recalled. 

The patch database recommends a replacement patch when you 
search by patch ID and find a recalled patch. 

• Patch not available 

A patch might be unavailable if, for instance, it has a dependency that 
requires the installation of a product that needs to be purchased 
separately. 
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Resolving Patch Conflicts 

These are the possible conflicts that can come up during an analysis and 
how to resolve them: 

• Behavioral conflict: A behavioral conflicts generally means a 
selected patch should not be installed with a patch installed on your 
system. You must choose between the new patch and the exist! ng one. 
View the details for each patch to decide which you want. If you 
choose to leave the existing patch installed, remove the conflicting 
patch from your selected patch list and perform another analysis. 

If two selected patches conflict, view the details for each patch and 
decide between them. Generally, you should select the patch with the 
highest rating unless a newer patch fixes a specific problem. 

• Structural Conflict: A structural conflict indicates that both 
patches will replace the same software file on your system. Check the 
revision numbers descriptions When two patches have structural 
conflicts, you should verify the revisions and install one or both of the 
patches as needed. This is a rare occurrence that when encountered 
can lead to unexpected behavior when a patch is effectively partially 
superseded. A structural conflict may not exclude the selected patch, 
but it will generally imply special handling. 

• Dependency Conflict: A selected patch or a patch already on your 
system requires another patch to be installed with it. This kind of 
conflict may be common. For example, you may select critical patches 
that have dependencies on noncritical patches. To resolve dependency 
conflicts with selected patches: 

1. Click on the dependent patch. 

2. Review its description and any superseded patches listed. 

3. If appropriate, add the patch to your selected patch list. 

4. Analyze for conflicts again to verify that the conflict is resolved. 

5. If you don't want the patch, de-select and remove it from your 
selected patch list. Analyze for conflicts again to verify that the 
conflict is resolved. 


Chapter 3 


53 





Acquiring Patches 

Resolving Patch Conflicts 


• Recalled: A Recalled patch has been removed from distribution. To 

find an alternative patch: 

1. Click on the patch name to view its details. 

2. Look for a recommended alternate patch, usually explained in the 
Warning/Description field or the final patch listed under 
Predecessor patches. 

3. Add the recommended alternative patch. If you do not find 
information about an alternative patch, it might still be in 
development. Continue checking the ITRC to check for updates. 
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Patch depots let you simplify systems management by defining a 
common reservoi r of software to be shared by a group of systems. Depots 
let you centrally manage the work of defining and testing the modified 
software that results from patching. 
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Introduction to Patch Depots 

A depot isa software container present on disk, tape, CD-ROM, or 
network di rectory that you can use as a source for the swi nstal I software 
installation utility. You can create depots using the SD-UX packaging 
process. Customizable depots give you a powerful tool for managing 
software. 

Benefits of Using Patch Depots 

There are compel I i ng reasons to use depots for patch management: 

• Depots separate patch management from system management 

Patch management requires a number of unique ski I Is and is an 
ongoing task. This adds responsibilities to a system administrator's 
work load. With patch depots, a centralized team can define and 
support a standardized patch level that many administrators can use. 

• Depots can streamline installation 

I nstal ling software from a depot lets a single installation session load 
everything in the depot, no matter how many sources you use to 
create the depot. For example, combining all patches that cause 
kernel rebuilds into a single depot lets you install multiple patches 
from the depot but requires only one reboot. 

• Depots permit remote administration 

Depots let you install software without having to mount media. This 
saves ti me and lets you admi nister patches on remote systems—or 
systems that are just far enough away to be annoying). 

Types of Depots 

There are two types of depots: directory and tape. Each type has 
advantages in certain situations. 

A tape depot is a single data file that is accessed in a serial manner. 
Thisformat isnot limited to tape media. It is also a convenient method to 
transfer a depot over a network without using the SD-UX swcopy 
command. For example, this is how FIP transfers the .depot file 
delivered within any patch shell archive from the Patch Database or 
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Fulfillment Server (seeChapter 1, "I ntroduction,"on page 11). 

Also known as a network depot, a directory depot contains each 
packaged file (as well asSD-UX infrastructure) as distinct files in a 
directory. Although this format is not as easily transferable as a tape 
depot, it is much better suited to parallel access. This type of depot works 
best if you plan to access the depot from multi pie remote systems. 


NOTE All depots discussed in this document are directory depots unless 

otherwise indicated. 


HP-UX 10.x vs. 11.x Depots 

With HP-UX 11.0, HP significantly enhanced the abilities of the 
Software Distributor tools for handling patches. This changed the basic 
layout of the SD-UX software objects. The iayout_version attribute 
differentiates the old and new versions, with 10.x depots identified by the 
value 0.8 and 11.x depots indicated by 1.0. 


CAUTION Although you can use depots of with a 0.8 layout version on an H P-UX 

11.x system to provide software for use on H P-U X 10.x systems, you may 
encounter problems. HP recommends that you install patch 
PHCO_20078 (or its current replacement) before you create such depots. 
Otherwise, if you copy an H P-UX 11.x depot to an H P-UX 10.x system or 
iayout_version=o. 8 depot, data will be lost and the depot corrupted. 
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Patch Depots 

Patch selection, analysis, and monitoring are some of the more difficult 
administrative tasks required for HP-UX systems. Creating several 
types dedicated patch depots can reduce the effort required for patch 
administration. 

Periodic Patch Depot 

Periodic patch depots are generated on a regular basis, which varies 
according to the needs of your users. You may create this depot quarterly 
to match the release of the Support Plus media, monthly to ensure a 
moretimely inclusion of critical fixes, or only in advance of scheduled 
system downtime to take advantage of the opportunity for rebooting. 

There are two critical aspects for maintaining such a depot: 

• The patches should be tested on the target system configurations. 

• All dependencies must be met. (See "Dependency Analysis" on page 
63.) 

After you have created a periodic patch depot, you can install patches on 
production systems usingtheswinstall command with the 
match_target option enabled. (See Chapter B, "SD-UX Tools & Objects," 
for more information.) 

Critical Fix Patch Depot 

Creating a periodic patch depot often requires a significant investment 
in testing and analysis. You may not want to change such a periodic 
depot after it has been released—yet a system may still encounter a 
problem that requires a new patch. 

I n this situation, you may find it useful to create a critical fix depot that 
contains fixes to known problems in the current environment. You can 
use this depot to update any system that encounters a known failure or 
as a starting point for the next version of a periodic depot. 

(As with the periodic depots, critical fix depots should also include 
dependencies of the patches in the depot.) 
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Depending on the severity or probability of a given failure, you may want 
to place a newer patch in both the periodic and the critical fix depot. 

Patch Hubs 

While H P does not recommend such depots for general use, you may in 
some situations find it useful to create a "kitchen sink" depot that 
contains every patch that your users may ever need. This method can 
conserve disk space and act as a local resource to ensure local access to 
any needed patch. 

The problem with this approach, however, is that the results of an 
SD-UX matching operation may not produce a defined or tested 
environment. Although you may be tempted to give all users direct 
access to a patch hub, there are a variety of ways i n which a system 
administrator could perform an incorrect operation that could leave a 
system in an unknown state. Therefore, if you do create a patch hub, H P 
recommends that you restrict access to it or leave it unregistered, or be 
given restricted access (see "Depot Access" on page 65). 

If you fully understand the risks of patch hubs and decide to create one, 
you can use the following mechanisms to define subsets of the full patch 
hub: 

• Patch Bundles 

You can acquire patch bundles directly from HP, create them using 
the IUX make_bundles command, or get them using external tools 
such as those available through the I nterex Users Group. (These tools 
arediscussed in the paper Creating Custom Patch Bundles by 
Dominguez & Scott in the I nterworks 1998 proceedings, also 
availableat http :/ /www.interex.org). 

Such a bundle can be explicitly selected for installation, but 
numerous issues exist. See Chapter 5, "Patch I nstallation,"for more 
information on installation issues. 

• Explicitly patch selection with software and session files 

The SD-UX commands used to install patches provide both a software 
file (specified with the -f option) and a session file (specified with the 
-c option). These files give you a mechanism to explicitly select a set 
of patch software. Session files also let you specify SD-UX options in 
addition to the software list. This can be particularly useful when 
working with bundle wrappers. 
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Directly specifying bundles, patches, or patch filesets from the 
swinstall user interface or a software or session file is known as 
explicit selection. For software to be explicitly specified within a 
swinstall session without reported errors, all of the filesets specified 
must beableto load. For example, this would require separate 
bundles containing only 32-bit (Series 700) or 64-bit (Series 800) 
filesets. For example, a patch that has already been superseded by a 
patch found on the system will be excluded with an error. 

• Depot copy 

An alternative to explicit selection istoswcopy the patches included 
in the bundle or software/session fileto their own depot in which you 
can use an SD-UX matching operation successfully. 
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Creating a Patch Depot 

Once you have decided to create a patch depot and have identified and 
acquired the necessary patches, you can finally begin the actual creation 
of the depot. The more individuals, systems, and depots involved, the 
moretimeand energy you need todevoteto preparation. Even if you are 
the only person to use the depots, creating the correct depot environment 
now will help support any changes required later. 

Preparation Tasks 

Consider these issues before you put a depot into production: 

• Depot nami ng 

The SD-UX interactive user interfaces lets users select from a list of 
aval I able depots on a system. It helps the users when the depot name 
identifies the contents, especially when they must choose between 
several different depots or revisions of depots. For example, 
/depots/order_db/Y200iQi might contain the periodic patch bundle 
for the first quarter of the year 2001 for use on systems hosting the 
order entry database. 

• Disk considerations 

Depot operations can involve significant disk activity. You must make 
sure adequatedisk space is available. If you expect depot usage to be 
high, you must also consider the performance of the disk devices and 
interface cards. When your environment requires constant 
availability of the depot, you must also consider high availability 
storage solutions such as disk arrays or mirroring. 

• Network considerations 

Take into account the performance of the networking interfaces and 
the location of the depot within the network. Consider the 
performance of the server and the impact on others applications and 
users. I f you can access groups of remote systems only by a congested 
or expensive link, creating a mirror depots may be a valuable option. 

• Compression 

By default, SD-UX creates depots in an uncompressed state. You can 
conserve disk space and network bandwidth by setting the swcopy 
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option compress_fiies to true when you create the depot. 

• Depot access 

When you create a depot using swcopy, it is automatically registered. 
If thefinal form of the depot require more than a singleswcopy 
operation, you should make the depot inaccessible during the creation 
process. You can do this by setting the register_new_depot option to 
false during the initial swcopy session. 

Copying Existing Depots 

All SD-UX-packaged software (including patches) exists in a depot. You 
can therefore assumethat an initial depot is always available. You can 
copy one depot to another using the swcopy command (for directory 
depots), or to with the swpackage command (for tape depots). The 
following example shows how a copy depot on the default tape drive to 
/depots/testdepot on the current system while ensuring that all files 
are compressed: 

swcopy -X cott5>ress_files=true -s /dev/rmt/Om \*.\* \ 

@ /depots/testdepot 

(Theswcopy command is described in more detail in theswcopy(lm) man 
page and in 'The swcopy Command" on page 102.) 

Combining Patch Depots 

You may want to combine patch depots so that you can perform a single 
install and reboot for a given session. When multiple patch depots are 
combined, each is simply copied in turn. This may result in the depot 
containing patches and their replacements together. While an 
installation using such a depot should be successful, error messages may 
be produced during the operation and unpredictable results may be 
encountered if the active patch is removed in the future. Superseded 
patches can be removed from a depot via the cleanup utility (delivered by 
patch PHCO_19549or current replacement). When given the -doption 
and the full path to a depot, cleanup removes any superseded patches in 
the depot. The following command runs cleanup for testdepot: 

/usr/sbin/cleanup -d /depots/testdepot 

I f the cleanup command detects any superseded patches, the command 
lists them and prompts you to determine if those patches should be 
removed. 
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Figure 4^1 


Dependency Analysis 

Although the patch database and the SD-UX tools perform automatic 
dependency analysis, you may occasionally have to perform the analysis 
manually. This section describes how toanalyzedependencies. 

Figure 4-1 shows two supersession chains that have a mutual 
dependency. The supersession chains are shown in the vertical column, 
with the older patches on the bottom. A patch dependency is i ndicated by 
a dashed arrow pointing from a patch to the patch it is dependent on. 

Example of Dependencies Between Patches 


PHNE 18972 


.|l'- 

Patch Dependency 



Supersession Chain 





PHNE_19899 


PHNE_17662 

T 




PHNE_17051 


PHNE_17017 


For example, suppose that you need a critical fix found in patch 
PHNE_17051. 

1. Read the PH NE_17051 text file. 

For example, the PH NE_17051 file lists a dependency on 
PHNE_17017. 

2. Search the patch database for any dependent patches. 
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For example, searching for PHNE_17017 shows that the patch is 
recalled and is not available, but it has been superseded by 
PHNE_19899. 

3. Check the dependency information for any superseding patches. 

For example, the .text file for PFI NE_19899 shows a dependency on 
PFINE_18972. The Supersedes field (in the patch . text file or the 
patch database) shows that PFI NE_18972 has replaced PFI NE_17051. 
PH N E 18972 also has a dependency on PH N E_17662. PH N E_17662 
itself has been replaced by PHNE_19899, which you already selected. 

At this point, no unresolved dependencies remain, and you can install 
patches PH N E_18972 and PH N E_19899 onto the system. Even 
though you did not install the original patch (PHNE_17051), the 
cumulative nature of H P-UX patches ensures that the replacement 
patches include the needed functionality. 

Chapter 3 , "Acquiring Patches," has more information about using the 
patch database and dependency analysis. 
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Depot Access 

You will often want to restrict access to patch depots. This could be due to 
entitlements, training, geography, or the depot not being prepared for 
production. Two mechanisms exist to restrict access: depot registration 
and access control lists. 

Depot Registration 

A registered depot is visible and accessible to remote systems. When 
unregistered, a depot remains accessible on its own system without 
being visible to remote systems. For patch depots, this is usually 
sufficient for most needs. Registration tasks are done using the swreg 
command. See 'The swreg Command" on page 111 for more information. 

SD-UX Access Control Lists (ACLs) 

If you require more complex access control, the SD-UX access control 
lists (ACLs) let you restrict access with a high level of detail. You can 
specify access rights for individual products within a depot and 
individual users on specific systems. The rights can be further divided by 
the type of access granted. 

A full description of ACLs goes beyond the scope of this document. For 
more information, see the swacl(lm) man page or Managing FI P-UX 
SoftwareWith SD-UX, available from http://docs.hp.com. 
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This chapter describes a basic prcxess for installing patches onto an 
H P-UX system. It provides a general checklist of tasks that you can use 
as a starting point for establishing your own installation process. 

Before you install patches, you should have: 

• Created a current system recovery image. (See Chapter 2, "Planning 
for Recovery") 

• Selected and acquired the patches you wish to install. (See Chapter 
3, "Acquiring Patches.") 

• Madesurethe installation depot contains all dependencies and is free 
of superseded patches. (See "Dependency Analysis" on page 63.) 
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System Preparation 

Even if your patch depot is ready, there is more to be done to prepare for 
any system modification. 

Back-ups, Back-ups! 

Even though this document has so far focused on backi ng up system 
software, data backups still matter. If you have any question about your 
abi I ity to mai ntai n the stabi I ity or reproduci bi I ity of user data, you must 
resolve it before proceeding. Although disk arrays and mirroring provide 
excellent protection from hardware failures, software failures and 
operator error are not hindered in their destructive ability. 

While the risks may be small, the costs can be huge. 

A Note on Change Management 

Computer systems are complex environments and system 
administrators are often driven by constant and critical interruptions. 
When you work with multi pie systems and system administrators, it is 
easy to get confused, make mistakes, and complicate the analysis of 
system failures. 

If you do not already have such a process, you should consider 
establishing a formal change control process for critical systems. 
Although a smaller data center would receive less benefit, such a process 
is almost essential in a large or growing environment. 

A formal change control process should include: 

• Clear ownership of each change 

The submitter of a change request becomes the initial owner of a 
task. By requiring a formal handofftoany new owners, the individual 
responsible for executing the change can quickly be identified. 

• Change review and approval 

By requiring a period of review and authorization, senior 
administrators and management can provide guidance and ensure 
that business needs are not controlled by technical decisions. 
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• Centralized change database 

Keeping change records on a protected central system prevents their 
loss when a system failure occurs. You can construct the database to 
provide access to experienced administrators and to provide visibility 
of upcoming changes to system users. 

System Activity 

TheSD-UX tools used for patching rely on DCE and networking support 
for even the most basic functions. For this reason, most H P-UX 
documentation recommends that the system be in run-level (init) 2 or 
higher—the multi-user states that are usually associated with active 
systems. 

This is not meant to indicate that updates should take place on active 
systems. Both the initial state prior to the installation and the final state 
upon completion should be supported and stable environments. During 
the installation process, system files, libraries, and commands are 
gradually changed. Scripts may kill and restart daemons. Commands 
and libraries may not match the currently running kernel. The system is 
between supportable configurations. 

Experience and recovery planning should be your guide. Halt any 
non-critical applications, and don't start any new processing. Remember 
that the risk is not only to the failure of an application, but to the system 
being left in a partially installed and corrupted state. 

Patch Committal 

When installing a large numbers of patches, such as a Support Plus 
patch bundle, it is not uncommon for some of the patches to already be 
present or superseded on the target system. If it becomes necessary to 
return to the initial state by removing the new patches, patches that 
were already there may be inadvertently removed. If a superseding 
patch present before the install is removed, the superseded patch that 
was to have been loaded will not be present. Each of these conditions can 
result in a patch required to fulfil I a dependency being removed. 

One method that can be used to avoid these issues is to perform a 
system-wide commitment of all patches prior to the installation of the 
new set. This causes the initial patched state to become the minimum 
system environment. The committed patches cannot be removed, and the 
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current patch level becomes a low-water mark. An attempt to remove all 
active patches can only delete those that are newly delivered. 

The recommended method for performing a system-wide patch 
committal is through the cleanup utility. Delivered by patch 
PHCO_19549PHCO_19550, the -F option directs cleanup to commit 
active and superseded patches. This not only sets a hard floor to the 
patch level, it also reclaims the disk space required to support rollback 
operations. (See 'The cleanup Command" on page 114 for more 
information.) 

While patch committal has benefits, there is also a cost. If a committed 
patch must be removed, the patched products must be reinstalled to 
provide the older versions of files. Selected reinstallation and Installed 
Products Database (I PD) modification can be a complex and risky 
operation. Before you commit patches, H P strongly recommends that you 
create a recovery image for your system. You can use this image if you 
need to return to the uncommitted state. Do not commit patches unless 
there is an immediate need. 
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Planning for System Reboot 

Thecoreof the HP-UX operating system is the kernel. Most kernel 
(PH KL) and many networking (PH NE) patches require that the kernel 
be rebuilt and restarted. The only method currently available to restart 
an H P-UX kernel is to reboot the system. 

When is a Reboot Needed? 

A flag in each patch's file and a fileset attribute within the patch itself 
indicate which patches require a reboot. To determine if a patch requires 
a system reboot: 

Look at the Automatic Reboot in the patch's .text file. 

Usetheswinstall GUI. You are prompted before the system installs any 
patches that require a reboot. 

Usetheswiist command to examine the is_reboot attribute of patch 
filesets. For example, to check the patches in /MyOepot: 

swlist -d -1 fileset -a is_reboot PH\* @ /I^Depot | grep true 

swlist -d -1 fileset -a is_reboot *.*, c=patch @ /MyDepot \ 

I grep true 

Ti mi ng of the Reboot 

The section, "System Activity" on page 69, discusses the fact that the 
system is in an unknown state until the installation process completes. 
This ambiguous condition exists until any required system reboot and 
configuration steps are completed. Not only is a reboot often required, 
but it should also not be unnecessarily delayed. Despite this and the 
cautions regarding system activity, it is certain that at times users and 
applications will remain active during an install and need to be prepared 
before a reboot can occur. 

This becomes an issue when the swinstalI command line interface is 
used. The CL I will not allow an installation that will require a system 
reboot to begi n unless the an override option (-x autoreboot=true) is 
specified. If specified, the autoreboot option instructs swinstal I to 
reboot the system whenever required. This does not allow any time or 
warning before the system is halted. 
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Installation 

Installation should be simple and quick if you have created proper depot 
and prepared your system. There are complex methods of patch 
installation, and some are mentioned in this document. Unless a special 
need exists, avoid using them unnecessarily. The goal is to have all 
systems at a common level with the least amount of overhead. 

Using the SD-UX Matching Operations 

The H P-UX lO.X versions of SD-UX do not recognize patches as being 
distinct from products. To select only the patches required by the target 
system, usethematch_target option. This option searches the target 
system for the ancestor filesets of every patch in the depot. Every patch 
with an ancestor present on the target system will be installed. 

The match_target operation operates across the entire depot. It cannot 
be filtered or restricted to only those patches found within a specific 
bundle. To load the required patches found in /mydepot: 

swinstall -s /mydepot -x match_target=true \ 

-X autoreboot=true 


Limitations: 

• The match_target option applies to both patches and non-patch 
software in the same depot. There is no way to ensure that patches 
and non-patch software are installed in the correct order. This 
complicates the process of software updates and requires that you 
keep patches i n separate depots from other software. This also makes 
it impossible to install both a product and its patches in a single step. 

• SD-UX cannot determine when patches are superseded by other 
patches. You must manually remove superseded patches from your 
patch depots to prevent them from being used again. 

• All patches in the source depot that correspond to software on the 
target system are selected. There is noway to filter them according to 
patch type or level of severity. 
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Installing to a Committed Patch State 

Patch commitment may take place during patch installation, or after the 
fact. If the file /var/adm/sw/patch/PATCH_NOSAVE exists during 
installation, any patches will be installed directly to a committed state. 
This file can be created by the root user with thetouch(l) command: 

touch /var/adrti/ sw/patch/PATCH_NOSAVE 

To commit patches after they have been loaded onto a system, a special 
utility is required. The HP-UX lO.X patch PHCO_12140 (or current 
replacement) delivers the script /usr/sbin/cieanup. One of the 
functions of this tool is to commit the currently installed patches. This is 
discussed in more detail in 'The cleanup Command" on page 114. 
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Installing Support Plus Patch Bundles 

Follow this procedure to install patch bundles from the Support PI us CD. 
For complete information on Support Plus, see "FI P Patch Bundles" on 
page 31 and the Support Plus User's Guide, available on the Support 
Plus CD and at http://docs.hp.com. 

Step 1. Mount the CD 

1. Open a terminal window and become root on your system. 

2. If the CD drive is external, switch it on. 

3. Put the appropriate Support PlusCD intothedrive. Wait for the busy 
light to stop blinking. 

4. If necessary, define a new directory as the mount point for the CD 
drive. For example, to define/cdrom as the mount point, enter: 

mkdir /cdrom 

5. If necessary identify the drive device file: 
ioscan -fnC disk 

This command lists all recognized CD drives and their associated 
device files. The file name will be something similar to 

/dev/dsk/clt2d0. 

6. Mount theCD drivetothe mount-point directory: 
mount -r /dev/dsk/clt2d0 /cdrom 

If the CD drive's device-file name is not clt2d0, use the name you 
found using ioscan in Step 5 above. 

7. You can now access the CD via the mount-point directory. For 
example: 

Is /cdrom 
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Step 2. Check for Last-Minute Information 

Support Plus often contains last-minute information. Before proceeding, 
H P strongly recommends that you read the documentation for each 
bundle or patch you wish to load. There are several important sources of 
information: 

• Check the HP IT Resource Center for information about 
recommended patches: 

http://itrc.hp.com/ 

Select the Maintenance and Support page, then select the appropriate 
patching tools. 

• Refer to the Support Plus web site for additional information: 
http://software.hp.com/SUPPORT_PLUS/ 

• Refer to the Read Before Installing document that accompanies the 
Support Plus CD. This short document contains up-to-date 
information about known problems with patches in recent Support 
Plus releases. 

• Each patch bundle has its own readme file. This file contains 
additional installation instructions, notes about problems in previous 
releases, a list of patches (and their dependencies) in the bundle, 
changes si nee the last release, and a listing of disk space usage. You 
can print or view these files directly from the CD. For example: 

more /cclrom/XSW800GR1020. readme 

• Each patch has an accompanyingtext file in the /cdrom/TEXT_FiLES 
directory. This file provides detailed information about the patch. 
(Patch text files are also included with individual patches that you 
retrieve from HP.) You can print or view these directly from the CD. 
For example: 

more /ccirom/TEXT_FILES/PHCO_12140.txt 

• Each bundle readmefile is also available in HTML format. These files 
contain hyperlinks to the patch text files. You can enter a URL into a 
web browser to view these files directly from the CD. For example: 

file:/cdrom/XSW800GR1020.readme.html 
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• Diagnostic products have readme files and additional information in 
the /cdrom/DiAGNOSTics directory. Some information is in Adobe® 
Portable Document Format (PDF) files. A free version of the Adobe 
Acrobat® Reader is available at: 

http://www.adobe.com 


To simplify sharing of patch information, you may wish to copy the 
documentation files onto your own system. The hyperlinks from the 
FITML bundle readme files to the patch text files will work as long as 
the FITML files reside in the same directory as the text_files 
subdirectory. 


If you mounted the CD on the system that is the target for the patch or 
diagnostic installation, proceed to "I nstall the Selected Bundles" on page 
77. 

Step 3. (Optional) Set Up Sharing for Remote Systems 

To enable direct access from one or two other systems, you must register 
a Support Plus bundle with the swreg command. For example, to register 
thexsw800GRi020 bundle if the Support Plus CD is mounted to/cdrom: 

1. Register the depot: 

swreg -1 depot /cdrom/XSW800GR1020 

2. Install the bundles (see "I nstall the Selected Bundles" on page 77). 

3. Disable remote access by unregistering the depot before unmounting 
theCD: 

swreg -u -1 depot /cdrom/XSW800GR1020 

Step 4. (Optional) Set Up Hard Disk Access 

If more than two systems must access the depot, or if you cannot 
dedicate the CD drive to the Support Plus CD, HP recommends that you 
copy the patch depots to a hard disk using the swcopy command. For 
example, with the CD mounted at /cdrom, use: 

swcopy -s /cdrom/XSW800GR1020 \* @ /var/tirp/I^Depot 
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Notes 


This copies the contents of the xsw 800 gri 020 bundle and depot to the 
local system under the /var/tmp/MyDepot directory. The new depot is 
automatically registered for use by remote systems. 

• HP recommends that you do not merge depots created on different 
versions of H P-UX. Also, H P recommends that both the host system 
and depot should have the same major HP-UX version (for example, 
10.x). 

• If the swcopy interactive user interface appears, an unexpected 
condition was encountered and you may need to enter additional 
information or take other action. 

Step 5. Install the Selected Bundles 

Each bundle on the Support Plus CD is built, tested, and intended for 
use as a unit. Although you can install individual patches from each 
bundle, you must carefully analyze the readme files to ensure you do not 
overlook dependencies on other software in the bundle. 

To ensure greatest reliability, HP recommends the following tasks for all 
systems: 

1. PI an for system down ti me 

Even though theswinstall command used for installing the bundles 
requires that the system has networking enabled, it is prudent to 
limit system activity during any installation. Also, Support Plus 
bundles commonly include patches that require a system reboot. 
Therefore, you should plan the installation for an appropriate time 
and announce a system outage to the users ahead of time. 

2. Create a system backup 

Some amount of risk is involved in any system modification. You 
should implement a recovery plan as an insurance policy against a 
system failure. One recovery technique is to use H P's Ignite-UX tools 
(available from http://software.hp.eom/products/l UX/) to create 
recovery i mages. 

3. Re/iewthedocumentation 

The bundle readme files may contain additional installation 
instructions and other important information. Although you should 
already have reviewed the patch documentation, it is wise to recheck 
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the readme files before installing. See "Check for Last-Minute 
I nformation" on page 75. 

4. I nsta11 the patch bundles 

HP recommends that after you have selected a bundlefor installation 
(see"HP Patch Bundles"on page 31), you install thebundleusingthe 
matching operations of the swinstall command. For example, to 
install from a CD mounted and registered on the system grendei: 

swinstall -s grendei:/ccirom/XSW800GR1020 \ 

-X match_target=true -x autoreboot=true 

You can use the swinstall command's preview mode 

(-p option) to get an idea of what to expect for the bundle you want to 

install. For example: 

swinstall -p -s grendei:/cdrom/XSW800GR1020 \ 

-X match_target=true -x autoreboot=true 


NOTE If the swinstall interactive user interface appears, an unexpected 

condition was encountered. You may need to enter additional 
information or take other action. 
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Finishing Touches 

Once you have completed the installation, you must verify the actions 
taken and begin preparations as the next cycle begins. 

Verifying the I nstallation 

Software Distributor maintains a database of software that it controls 
known as the I nstalled Products Database or I PD. Theswverify 
command is provided as a method to compare the data within the I PD 
with the actual system directories and files. When verifying installed 
software, swverify checks software states, dependency relationships, file 
existence and integrity. 

The swverify command can be used to verify a patch bundle or even a 
single patch, but it is recommended that a wildcard be used to verify all 
products and patches on the system. This can be done using: 

svrverify \* 


Checking the Logs 

Each SD-UX command logs messages to/var/adin/sw/sw<task>. log, 
where task is the name of the SD-UX command. This contains a terse 
summary of command activity. (You can specify a different logfile by 
modifying the logfile option. See the SD-UX manual for more 
information.) 

A swagent process performs the actual operations for each many SD-UX 
commands, including swinstall, swcopy, and swremove. This log file is 
much more complete. For example, it includes the output from 
installation scripts, which would not be in the command log filefor 
swinstall. This log is located at /var/adm/sw/swagent. log. For depot 
operations, swagent logs messages to the file swagent. log beneath the 
depot directory (for example, / var / spool/sw/swagent. log). If you 
experience problems with one of the SD-UX commands, the swagent log 
is a good pi ace to look for more information. 

The cleanup command can helpyou manage SD-UX log files. See 
"Cleanup Command" on page 22. 


Chapter 5 


79 





Patch Installation 

Finishing Touches 

Erroneous Errors and Warnings 

Unfortunately, some errors and warnings output by a SD-UX install or 
verify do not indicate serious problems. Examples of false errors and 
warnings are shown below and most likely refer to incorrect mtime, 
cksum, mode, owner ID and group ID. These are usually artifacts of 
incorrect patch creation and are typically not indicative of a real system 
problem. 

Some examples: 

WARNING: Directory "/usr/sam" should have mode "555" but the actual 
mode is "755". 

WARNING: Directory "/usr/sam" should have group,gid "bin,2" but the 
actual group, gid is "sys,3". 

WARNING: Fileset "SW-DIST.SD-FAL,1=/,r=B.10.20" had file warnings. 

ERROR: File "/opt/graphics/common/bin/gamma" had a different mtime 
than expected. 

ERROR: File "/opt/graphics/common/bin/gamma" should have cksum 
"3372307748" but the actual cksum is "4034162912". 

ERROR: Fileset "Xserver.AGRM,1=/,r=B.10.20" had file errors. 

Another potential false error involves missing files. This is often the 
result of the delivery of a file to and subsequent move from a temporary 
location or name. Some patches initially deliver files to a temporary 
location before moving them to the final location. When thefileis 
delivered to this temporary location, the I PD is updated with this 
information. The file is then moved to its final destination by the patch 
scripts. Later, when the system is verified, the newly delivered file is 
looked for and not found in the initial delivery location resulting in a "file 
missing"error in theswagent.logfile. A popular initial patch filedelivery 
location is /usr/newconfig or as a .tmp file. 

Here is an example of a missing file error: 

ERROR: File "/usr/newconfig/usr/ccs/bin/ld" missing. 

ERROR: Fileset "PHSS_10764.PHSS_10764,1=/,r=B.10.00.00.AA" 
had file errors. 

Missing files are a critical problem that deserves attention. However, at 
the current time, SD-UX does not have a method for dealing with 
patches delivering files to and moving them from initial locations so it 
may be difficult to determine if a real problem exists. It is an issue that 
HP is working with patch creators to resolve in the future. In the 
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meantime, you can resolve this problem if it occurs by looking for clues 
that the missing file was delivered under one name or location and then 
moved to a different name and location. Look in the swagent.log file for 
clues from the /usr/newconfig and .tmp files. Then locate the delivered 
filein its final destination to verify that it is not missing. For instance, in 
the above example, although the file /usr/newconfig/usr/ccs/bin/id 
does not exist, the permanent file /usr/ccs/bin/id does exist. 

A very similar false error totheaboveisthe missing .ofile. Before being 
archived into a library, a .ofile will be delivered to a temporary location. 
The I PD is updated and then the file is archived to the appropriate 
library. When the system is verified, the .o is justly no longer found in 
the initial location resulting in a "file missing" error in the swagent.log 
file. An example is shown below: 

ERROR: File "/usr/conf/lib/vm_text.o" missing. 

ERROR: File "/usr/conf/lib/vm_vas.o" missing. 

ERROR: File "/usr/conf/lib/vm_vhand.o" missing. 

ERROR: Fileset 

"PHKL_10757.PHKL_10757,1=,r=B.10.00.00.AA" had 
file errors. 
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This appendix defines basic patch terminology and concepts. 

Patch management differs in many ways from standard forms of 
software management. Certain terms and actions apply only to patching. 
Although you can support your systems without understanding patch 
concepts, understanding these concepts will help you rely less on 
external tools or experts. 

A patch is an incremental change to the released software. Patches 
deliver defect fixes, performance enhancements, and sometimes new 
functionality. You can load patches in response to a system failure or to 
proactively avoid problems in the future. 
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Ancestors and Patches 

Ancestors are one of the basic concepts of patch operations. The 
ancestor of a patch consists of the preexist! ng software that is bei ng 
modified or replaced. For a patch that delivers a new version of a single 
file, the ancestor is the original version of that file. 

Ancestors are usually managed between grouping of files known as 
filesets. (Filesets arediscussed in detail in Appendix B, "SD-UX Tools & 
Objects.") Filesets permit several patches to modify a single product or 
single patches to modify several products. Patches created for FI P-UX 
lO.X releases are generally created within a singlefileset. 

Figure A-1 shows a simpleexample in which patch phco_oioo modifies 
the four filesets of product Prod. ThePHCo_oioo patch fileset must 
deliver files to four distinct ancestor filesets. 

HP-UX lOJC patch and ancestors 


Product 


Patch 



One Patch 
One Fileset 


This delivery Strategy can create complications. If you install phco_oioo 
on a system that has Prod installed without fileset fsd, the files intended 
for fileset fsd arestill delivered. They are assigned to one of the other 
three filesets because the system does not have enough information on 
file ownership. If you install fileset fsd later, you would have to remove 
PHCo_oioo, install fileset FSD, then re-install phco_oioo. 
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Figure A-2 


Patch Supersession 

Patches for HP-UX products are cumulative. This means that any 
individual patch supplied by HP must contain all aspects of any 
preceding patch. The newer patch is said to supersede all earlier patches. 
A series of patches, each replacing the previous patch, forms a 
supersession chain. I n general, the patch numbers will increase along a 
patch supersession chain. 

Patch Supersession Chain 


PROD.FS 



PHCO 1000 



PHCO 2000 



PHCO 3000 


Figure A-2 shows a supersession chain. The SD-UX-packaged product 
Prod, is initially patched by phco_iooo. This patch is superseded by 
PHCO_2000 which is superseded in turn by phco_3000. When a patch is 
superseded, it remains on the system, but is not active. Only the top 
patch of the chain is in the active (applied) state. 

Since patches aredesigned to be cumulative, it is not required to have all 
patches in a supersession chain installed. I n fact, the presence of a 
superseding patch prevents the installation of any preceding patch. This 
prevents an older patches from replacing newer versions. 

Patch supersession should not be considered in a negative manner. While 
a newer patch usually contains additional fixes, the fixes may not be 
critical. The known qualities of an older patch may have greater value 
than the non-critical improvements in a subsequent patch. 

Patch Rollback 

The installation of a patch differs from the installation of a product in 
several ways. One of the key differences is the ability to perform patch 
rollback to restore the pre-patched behavior. 

When a patch is loaded onto a system, the default behavior is to save 
copies of all files patched prior to loading the new versions. Ifthe patch is 
removed, these saved files are restored. Only the active member of a 
supersession chain can be removed, but as each superseded patch 
returns to the active state, it becomes eligible for removal in future 
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Patch Mechanics 

sessions. Figure A-3 shows the save areas for the Prod.FS supersession 
chain (shown above in Figure A-2). 

Patch Rollback 



The Prod.FS fileset contains the relocatable object files foo.o and 
bar.o, both having a of revision 1.0. When phco_iooo is loaded, it 
delivers a new version of foo.o. When this happens, the version 
delivered with the original product (vl.O) is stored in a save area 
associated with phco_iooo. 

When PHCO_2000 is loaded, it delivers a new version of bar.o. As a 
cumulative patch, it must also deliver the version of foo.o that was 
delivered by phco_iooo, even though it did not change. The versions of 
foo.o and bar .o that existed on the system before phco_2000 are then 
stored in the save area. 

Finally, patch phco_3000 delivers new version of both files, and the 
existing files on the system are preserved in a save area associated with 

PHCO_3000. 

If you remove patch phco_3000 from the system, the files in the save 
area are automatically restored to the system, and patch phco_2000 
again becomes the active patch. If you removed each patch in sequence, 
you would eventually return Prod.FS to its original state. 
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Patch Commitment 

The rollback mechanism is not without cost. Cumulative patching 
ensures that the amount of change delivered by a patch increases during 
the life of a supersession chain. In some cases, multiple copies of the 
same file are preserved. 

The disk space used to support patch rollback may be reclaimed through 
patch commitment. When you commit a patch, H P-UX deletes the 
patch's associated save area—which means you can no longer directly 
remove the patch. The product remains patched until you update to a 
newer version or removed the product from the system. 

Because the information lost describes the state before the installation of 
the patch, rei nstal I i ng the committed patch does not restore the rol I back 
ability. Also, if you commit any patch in a supersession chain, you lose 
the ability to restore any prior patches—although you can now reclaim 
the disk space from the save area for those patches. 
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Patch Dependencies 

To become fully active, a patch may require changes toother areas of the 
system. Because patches are cumulative, the areas affected by a single 
patch are limited. To inform you when other changes are required, a 
patch may document a dependency against patches responsible for 
these other areas. 

The different types of dependencies are documented in a patch's .text 
file or in the readme attribute of each patch. The fields used in the .text 
file are filled in as appropriate for each type of dependency. 


Special Dependency Types 

Patch dependencies include these special types: 

• Standard Dependency 

An execution-time software dependency without any exceptions or 
conditions. For example, the commands in PHCO_1000 cannot be 
used without the kernel support of patch PH KL_1234 because of a 
dependency. Standard dependencies are documented in the Patch 
Dependencies field of the. text file for each patch. 

• Ordered Dependency 

An installation time software dependency without any exceptions or 
conditions, but the dependency must be loaded first for the 
requirement to be satisfied. These are documented in the Patch 
Dependencies field and/or the Special Installation Instructions field. 

• H ardware Dependency 

Certain patches are only applicable to specific system models. These 
system-level dependencies are documented in the Hardware 
Dependencies field. 

• Other Dependencies 

There are dependencies that do not fit the other types. These include 
optional dependencies required under specific circumstances or 
hardware dependencies below the system level. All miscellaneous 
dependencies are explained in the Other Dependencies field. 
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The HP-UX Patch 

An H P-UX patch is a partial delivery of software that fixes defects found 
in the original. I n some cases, the patch extends the original 
functionality. Each patch includes a set of properties that are 
documented in an associated text file. This section will examine some of 
these properties, the .text file is described in detail in Appendix C , 
'The Patch Text File." 

Patch Status 

Almost every patch created is intended for general release to all 
customers, but the patch may transition into different release states. The 
current release state, known as the patch status, can be found within the 
.text file and is also displayed when viewing patches within the ITRC. 
Thedata within the .text file reflects the initial stateof the patch due to 
the static nature of the file. The ITRC data, and in particular the Patch 
Database itself, provide the current patch state. 

The following patch states are used by all patches that should be 
available to customers. Any value other than those listed here denotes a 
patch that should be restricted and used only with full understanding 
and great caution. 

• General Release 

A status of General Release indicates a patch that is approved for 
widespread use and is the active member of the supersession chain. 
As the newest available patch, it contains all known fixes to date for 
the target software. 

• Special Release 

A special release patch is an active patch not intended for use by all 
customers. Patches may be created as special release if a set of 
customers require nonstandard behavior or configuration-specific 
change that might cause problems for general use. 

• General/Special Superseded 

When an active patch is replaced by a newer version, it enters the 
superseded state. Applicable to both General and Special Release 
patches. (A newer patch does not imply that the previous patch was 
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defective. The newer version may only deliver additional changes of a 
non-critical nature.) 

• General/Special Recalled 

Under certain conditions, HP may recall a patch and removed from 
general distribution. As with superseded patches, you should weigh 
the issues documented in the recall notice against the value of the 
current patch fixes and cost of system change. Although the generic 
recommendation is to remove and replace the patch, the appropriate 
action for your specific system may vary. 

The Critical Patch 

While each patch is created to improve upon the original version of the 
ancestor software, certain patches address issues of the highest priority 
and are considered critical. Examples of conditions that cause a patch to 
be marked critical include data loss, data corruption, system panic, or 
system hang. HP designates patches as critical in response to the 
severity of a failure, not the probability you will actually encounter the 
failure. 

Patches are classified into one of three categories: 

• Not critical 

No part of the patch addresses a critical failure. While there may still 
be compelling reasons to install such a patch (such as a performance 
enhancement), there is no reason to take any immediate action. 

• Critical 

The patch delivers a new fix for a critical failure. The severity of the 
defect is such that you should evaluate the patch for applicability to 
your systems and environments. Even if you take an extremely 
conservative approach to making system changes, a critical 
designation may still give you good reason to load the patch to avoid 
the possi ble failure. 

• Not critical, but supersedes a critical patch 

The patch does not contain critical fixes, but delivers critical content 
that was introduced within a patch that has been superseded within 
the same patch chai n. 
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Patch Identification 

An H P-UX patch name consists of a four-character type identifier, 
followed by an underscore, followed by a four- or five-digit patch number. 
The patch number is unique to each patch, regardless of the patch type. 
The currently defined patch types are: 


PHCO 

Commands and libraries 

PHKL 

Kernel 

PHNE 

Networking 

PHSS 

All other HP-UX subsystems 


NOTE This naming convention is not recognized by theSD-UX software 

management tools. 


The Patch Shar File 

Theshar command produces shell archive files, a useful and portable 
way to package groups of files for transfer between U nix-based systems. 
When you acquire a patch from the Patch Database within the ITRC or 
from the Fulfillment Server (FFS), it is packaged as a shell archive. 
(These sources are described in more detail in Chapter 3 , "Acquiring 
Patches.") 

When exercised by the shell, the patch shell archive recreate two files 
within the current working directory. These are the .depot and .text 
files. The .depot file is an SD-UX tape-style depot containing the actual 
patch. The . text file is the complete documentation for the patch, 
including descriptions of the symptoms and defects repaired by the 
patch, special installation instructions (if any), dependencies, and the list 
of files contained within the patch. 
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For More 
Information 

This appendix provides an overview of Software Distributor commands 
for HP-UX (SD-UX-UX) commands and concepts as they apply to 
patching. Many patch operations involve some aspects of the SD-UX 
tools, but you need only a small subset of SD-UX functionality for 
patching operations. SD-UX functionality that is not appropriate for 
patching is not discussed. 

SD-UX is included with the H P-UX Operating System and by default 
manages software on the local host only. You can also enable SD-UX to 
install and manage software simultaneously on multiple remote hosts 
from a central controller. Consult the SD-UX manual for more 
information. 

This appendix does not discuss SD-UX remote operations or installations 
involving NFS diskless clusters or alternate roots. 

This appendix does not present a comprehensive view of SD-UX. For 
in-depth information, consult the SD-UX manual. Managing H P-UX 
Software with SD-UX, available at http://docs, hp.com. 
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The Basic SD-UX Object Types 

Software Distributor uses a variety of object types. This section gives you 
a simplified view of the object types that relate to patches. You can find 
formal definitions in Managing H P-UX Software with SD-UX and the 
sd(4) man page. 

The Fileset 

A fileset is one or more related files, grouped into a manageable unit. It 
describes a unique subset of the files that make up a product. A fileset 
may include scripts that control installation and removal, but these are 
rarely seen at the fileset level in lO.X patches. 

I n general, patches are created and managed at the product level, and 
patch filesets are delivered only within a patch product. Therefore, you 
should avoid selecting patches at the fileset level, even though SD-UX 
permits this kind of selection. Selecting patches by fileset level may 
cause a fix to be only partially applied. 

The Product 

An HP-UX patch is structured as a single SD-UX product that contains 
one or more filesets. HP-UX lO.X include SD-UX control scripts at the 
product level. These scripts implement the patch infrastructure. HP-UX 
lO.X patch products generally contain a single fileset. 

The Bundle 

A bundle encapsulates products and filesets into a single software object. 
Bundles provide a convenient way to group software objects together for 
easy selection. More than one bundle can contain the same software 
objects. A bundlecan bethought of asa virtual "configuration"of 
software. 

H P provides several types of standard patch bundles. See "Support Plus 
Patch Bundles" on page 32 for more information. 

The Depot 

A depot is a di rectory that contai ns software products or bundles that are 
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available for direct or remote installation. You can change the contents of 
a depot. A depot can also be a distribution media (e.g. tape or CD-ROM) 
or a single, serial filethat contains products or bundles. 
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Patch-related Object Attri butes 

Each of the objects described in "Patch-reiated Object Attributes" on 
page 96 has a set of properties known as attributes. Attributes controi 
aspects of patch behavior and define patch properties and reiationships. 
The patch-reiated attributes are described beiow. You can view SD-UX 
object attributes with theswiist command (see'Theswiist Command" on 
page 108). 

ancestor 

• Appiiestofiiesets. 

• Lists thefiiesets that this fiieset modifies. 

• Thefoiiowing exampieshows patch PHKL_16750, which hasasingie 
fiieset that is aiso named PHKL_16750. This fiieset modifies seven 
ancestor fiiesets, found in five different products. 

swlist -1 fiieset -a ancestor PHKL_16750 

# PHKL_16750 

PHKL_16750.PHKL_16750AdvJournalFS.VXFS-ADV-KRN 
JournalFS.VXFS-BASE-KRN JournalFS.VXFS-PRG LVM.LVM-KRN 
OS-Core.CORE-KRN OS-Core.KERN-RUN ProgSupport.C-INC 


is_reboot 

• Appiiestofiiesets. 

• When set to true, is_reboot indicates that instaiiation of the fiieset 
wi i i cause the system to reboot. 

software_spec 

• Appiiesto bundies, products, or fiiesets. 

• Thesoftware_spec attribute (short for software specification) contains 
thefuiiy quaiified identifier for the bundie, product, or fiieset. The 
software_spec contains the object name and any version or 
architecture information. See "Software Specifications" on page 115 
for more information. 
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State 

• Applies to fiIesets. 

• A fileset's state attribute (also used for non-patch software) provides 
useful information about the installation state of software. SD-UX 
commands automatically keep track of software management 
operations by creating an I nstalled Products Database (I PD) and 
various catalog files that contain information about the software on 
the system. Some attributes are stored in the I PD only. 

An SD-UX operation leaves a fileset in one of the foil owing states and 
records it in the fileset's state attribute: 

installed (I PD only) 

The software was successfully installed but not 
configured. Although not every patch requires 
configuration, HP recommends that you move all 
patches left in the installed state to the configured 
state with the swconfig command. The swconfig 
command is not discussed in this tutorial, consult 
the swconfig(lm) man page or Managing H P-UX 
Software with SD-UX for more information. 

configured (I PD only) 

The product was successfully installed and 
configured. No further operations are required. 

available (depot only) : 

The software is ready for access. 11 can be used by a 
swi nstal I or swcopy session usi ng the depot as the 
source. 

corrupt I ndicates that errors detected in the execution 

phase of a swcopy or swi nstal I process left the 
software in an unknown state and that the software 
should not be used. 

transient I ndi cates that swi nstal I or swcopy was killed or 
aborted during the execution phase leaving the 
software in an unknown and incomplete state. The 
transient state differs from the corrupt state in that 
SD-UX did not detect the failure when it initially 
occurred. 
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I ntroduction to the SD-UX Commands 

This appendix discusses the SD-UX commands that reiateto patching. 
Thefoiiowing iist shows the commands, ordered by those most commoniy 
used: 

• swinstaii - instaiis and configures software products. 

• swcopy - copies software products for subsequent instaiiation or 
distribution. 

• swremove - unconfigures and removes software products. 

• swiist - dispiays information about software products. 

• swreg - registers or unregisters depots or roots. 

• swmodify - modifies software product information in a target root or 
depot. 

• swpackage - packages software products i nto a depot (di rectory or 
tape). 

Aii SD-UX commands run from the command iine. i n addition, swinstaii, 
swcopy, and swremove have an optionai GUi mode. 

Additionai concepts for using the SD-UX commands are discussed in 
"Other Options and Aids to Using the SD-UX Commands" on page 115. 
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Theswinstall Command 

The swinstall command is used to load patch softwarefrom a source 
depot and onto a target system. 

Synopsis swinstall [-1] [-p] [-v] [-S source] 

[-X option=value][software_selections] 

TIPS: • Because many patches aren't designed for individual installation, you 

should always use the automatic matching option (match_target) to 
install patches. 

• swinstall has numerous options that you should not use for patching 
because they lack dependency support. H P recommends that you use 
only the options discussed below. 


Table B-1 Patch-related command line arguments for swinstall 


-i 

Use an interactive user interface. If the environment variable DISPLAY is 
set to a valid X windows display, a graphical user interface is invoked. 
Otherwise a terminal user interface (TUI) designed for use on ASCII 
terminals is invoked. The GUI starts by default if you enter swinstall 
without any software_selections. 

-p 

Previews the install operation without performing the actual installation. 
Preview mode is not enabled by default. 

-V 

Requests verbose mode. This option affects only standard output and not 
the log files. 

-s source 

Specifies the depot (source) containing the software to be installed. 

-X option=value 

Sets the specified default option to the value given, overriding any other 
values for that option. Patch-related default options are specified below. 

See “Setting Default Values for Command Options” on page 117 for more 
information on setting defaults. 

software_selections 

One or more software specifications. See “Software Specifications” on 
page 115 for more information 
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Patch-related The following options have the most relevance to patching (see "Setting 
Options Default Values for Command Options" on page 117). Where appropriate, 

default values are shown. Forthefull set of availableoptions, consuitthe 
swinstall(lm) man page or refer to the SD-UX manual. 


Table B -2 Patch-related options for swinstall 


option=default value 

Menu Path in Interactive Interface 

Description 

autoreboot=false 

None (GUI waits for permission to reboot) 

Enables an automatic reboot upon completion of the software installation. 

autoselect_dependencies=true 

Actions^Autoselect dependencies (when marking 
software) 


When software is selected for installation with an SD-UX-enforced dependency, that software will 
automatically be selected for installation if present in the source depot and autoselect_dependencies is set 
to true. 


While few patches exist with dependencies enforced by the SD-UX tools, those that do employ them to 
enforce critical requirements of content and load order. This option should not be set to false unless 
directed by an HP Support Engineer. 


autoselect_reference_bundles=true 

None 

When set to true, any bundle wrappers within the source depot that contain software selected for 
installation will be automatically selected if the is_reference attribute set to true. Note that this does not 
mean all of the software listed in the wrapper will be selected, only the bundle wrapper itself. 

enforce_dependencies=true 

Options^Change Options^Enforce dependency 
analysis errors in agent 


Enforces software dependencies. When software is selected for installation with an SD-UX-enforced 
dependency, if the dependency is not present on the target system and is not selected for installation from 
the source depot, installation will only proceed if enforce_dependencies is set to false. 


While few patches exist with dependencies enforced by the SD-UX tools, those that do employ them are 
enforcing critical requirements of content and load order. This option should not be set to false unless 
directed by an HP Support Engineer. 


enforce_scripts=true 

Options^Change Options^Enforce script failures 

Each patch has several installation scripts associated with it. These scripts control all aspects of the patch 
infrastructure and may issue errors to protect the system from incorrect patch usage. This option should 
not be used unless directed by an HP Support Engineer. 

match_target=false 

Actions^Match What Target Has 
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Table B-2 Patch-related options for swinstall 

Selects all software within the source depot with an ancestor attribute that matches a fileset currently on 
the target system. 

This is the recommended method of installing patches from a managed depot, such as those provided 


directly from Hewlett-Packard. See Chapter 5, “ 

Patch Installation,” for more information. 

mount_all_filesystems=true 

Options^Change Options^Mount filesystems in 
/etc/fstab or /etc/checklist 

By default, swinstall requires that all filesystems listed in the systems /etc/fstab file are mounted prior to 
installation. Setting this option to false removes this restriction. 

reinstall=false 

Options^Change Options^Reinstall filesets even 
if the same revision exists 

Prevents SD-UX from re-installing (overwriting) an existing revision of a fileset. If set to true, filesets 
will be re-installed. WARNING: for HP-UX 10.20, this option may cause the data saved to support patch 
rollback to become corrupted. Do not use this option unless instructed to by an HP Support Engineer. 

source_cdrom=/SD-UX_CDROM 

None (default cannot be changed within GUI) 

Specify the device file of the CD-ROM to be used as the default. 

source_tape=/dev/rmt/Om 

None (default cannot be changed within GUI) 

Specify the device file of the tape drive to be used as the default. 

write_remote_files=false 

None 

Prevents installation of files to a target that exists on a remote (NFS) file system. By default, swinstall 
skips files that would be installed to a remote (NFS) file system (or that are already there). When set to 
true and superuser has write permission on the remote file system, the remote files are installed. 


Examples • I nstall from a CD mounted and registered on the system grendei: 

swinstall -s grendei:/ccirom/XSW800GR1020 \ 

-X match_target=true -x autoreboot=true 

• Use the swinstall command's preview mode (-p option) to get an idea 
of what to expect for the bundle you want to install. For example: 

swinstall -p -s grendei:/cdrom/XSW800GR1020 \ 

-X match_target=true 
-X autoreboot=true 
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The swcopy Command 

The swcopy command copies software from one depot to another. This 
can be particularly useful if software exists in several depots. For 
example, you can copy all of the contents of individual patchesintoa 
single depot from which the group can be loaded in a single session and 
with a single reboot (if needed). 

Note that the swcopy command automatically registers (enables remote 
access to) any depot that it creates. You do not need to use the swreg 
command on depots created by swcopy. (See 'The swreg Command" on 
page 111 for more information.) 

Synopsis swcopy [-i] [-p] [-v] [-S source] [-x option=value] 

[software_selections] [@ target_selection] 


Table B-3 Patch-related Command Line Arguments 


-i 

Use an interactive user interface. If the environment variable DISPLAY 
is set to a valid X windows display, a graphical user interface is 
invoked. Otherwise a terminal user interface (TUI) designed for use on 
ASCII terminals is invoked. The GUI starts by default if you enter 
swcopy without any software_selections. 

-p 

Previews the copy operation without performing the actual copy. 

Preview mode is not enabled by default. 

-V 

Requests verbose mode. This option affects only standard output and 
not the log hies. 

-s source 

Specihes the depot (source) containing the software to be copied. 

-X option=value 

Sets the specihed option to the value given, overriding any other values 
for that option. Patch-related options are specihed below. See “Setting 
Default Values for Command Options” on page 117 for more 
information on overriding defaults. 

software_selections 

One or more software specihcations. See “Software Specihcations” on 
page 115 for more information 

target_selections 

The absolute path name (directory location) to which you want the 
software_selections to be copied. If you specify a host with the 
directory, the syntax is host: /directory where the host name can 
be a name, domain name, or internet address. 
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Patch-related The following options have the most relevance to patching (see "Setting 
Options Default Values for Command Options" on page 117). Where appropriate, 

default values are shown. Forthefull set of availableoptions, consuitthe 
swcopy(lm) man page or refer to the SD-UX manual. 


Table B-4 Patch-related options for swcopy 


option=default value 

Menu Path in Interactive Interface 

Description 

autoselect_dependencies=true 

Actions^Autoselect dependencies (when 
marking software) 

When software is selected for copying with a registered dependency on other software, that other 
software will automatically be selected to be copied if present in the source depot and 
autoselect dependencies is set to true. 

autoselect_reference_bundles=true 

None (default cannot be changed within GUI) 

When set to true, any bundle wrappers within the source depot that contain software selected for 
copying will be automatically selected if the is_reference attribute set to true. Note that this does 
not mean all of the software listed in the wrapper will be selected, only the bundle wrapper itself. 

compress_f iles=false 

Options^Change Options^Compress files 
during transfer 

Setting this option to true causes swcopy to compress file before transfer to the target depot. This will 
conserve disk space and can enhance performance on slower networks (50 Kbytes/sec. or less), although 
it may not improve fast networks. 

enforce_dependencies=true 

Options^Change Options^Enforce dependency 
analysis errors in agent 

Enforces software dependencies. When software to be copied has an SD-UX-enforced dependency, if 
that dependency is not present on the target system and is not marked for copying from the source depot 
the copy will only proceed if enforce_dependencies is set to false. 

While few patches currently exist with dependencies enforced by the SD-UX tools, those that do employ 
them to enforce critical requirements of content and load order. This option should not be set to false 
unless directed by an HP Support Engineer. 

mount_all_filesystems=true 

Options^Change Options^Mount filesystems in 
/etc/fstab or /etc/checklist 

By default, swcopy requires that all filesystems listed in the systems /etc/f stab file are mounted 
prior to installation. Setting this option to false removes this restriction. 

reinstall=false 

Options^Change Options^Recopy filesets even 
if the same revision exists 

Prevents SD-UX from overwriting an existing revision of a fileset. If set to true, filesets will be recopied. 
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Table B-4 Patch-related options for swcopy 


source_tape=/dev/rmt/Om 

None (default cannot be changed within GUI) 

Specifies the device file of the tape drive to be used as the default. 

uncoinpress_files=false 

Options^Change Options^Uncompress files 
after transfer 

When set to true, files are uncompressed before swcopy puts them into the target depot. See also the 
compress f lies option. 

write_remote_files=false 

None 

Prevents copying of files to a target that exists on a remote (NFS) file system. By default, swcopy skips 
files that would be copied to an NFS file system (or that are already there). When set to true and 
superuser has write permission on the remote file system, files are copied to remote systems. 


Examples • With the CD mounted at /cdrom, copy the contents of the 

XSW800GR1020 depot to the local system under the 

/var/tmp/MyDepot directory 

swcopy -s /ccirom/XSW800GR1020 \* @ /var/tirp/MyDepot 

• Invoke an interactive session, usi ng the default depot at hostx as the 
source: 

swcopy -i -s hostx 

• Copy all patches in current directory to the depot /hub/patches 
(assuming root shell is /sbin/sh): 

for PATCHDEPOT in *.depot 

do 


swcopy -s $PATCHDEPOT \* @ /hiab/patches 

done 

• Copy a H P-U X lO.X format depot from the system oidsys to an 
HP-UX 11.x system. 

swcopy -s oidsys:/depot -x layout_version=0.8 \* \ 

@ /depots/oldsys 
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The swremove Command 

The swremove command deletes software that has been installed on your 
system. 11 also removes software from depots. 

Limitations Note that swremove has several limitations when used for patch 

operations: 

• You cannot use swremove to remove committed patches. 

• You should not use swremove to remove patch information that 
remains in the I PD after installing a new version of H P-UX. (See also 
'The cleanup Command" on page 114.) 

• I f you use swremove to remove a patch, you must make sure you don't 
"break" any software dependencies. If the removed patch fulfilled a 
dependency (which you can determine by the patch documentation), 
then you must satisfy the dependency by the rollback process or by 
installing another patch. 

• Removing a patch bundle does not automatically return you to the 
patch state that existed before you loaded the bundle. 

• swremove may not always be your first and best solution for error 
recovery. Make sure your other recovery methods are not more 
appropriate before you use this command. 

Synopsis swremove [-i] [-d] [-p] [-v] [-x option=value] 

[software_selections][ @ target ] 


Table B-5 Patch-related command line arguments for swremove 


-i 

Use an interactive user interface. If the environment variable DISPLAY is 
set to a valid X windows display, a graphical user interface is invoked. 
Otherwise a terminal user interface (TUI) designed for use on ASCII 
terminals is invoked. The GUI starts by default if you enter swremove 
without any software_selections. 

-d 

Operate on a depot rather than installed software. 

-P 

Previews the remove operation without performing the actual removal. 
Preview mode is not enabled by default. 

-V 

Requests verbose mode. This option affects only standard output and not 
the log files. Verbose mode is enabled by default. 
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Table B-5 Patch-related command line arguments for swremove 


-X option=value 

Sets the specified default option to the value given, overriding any other 
values for that option. Patch-related default options are specified below. 

See “Setting Default Values for Command Options” on page 117 for 
more information on setting defaults. 

software_selections 

One or more software specifications. See “Software Specifications” on 
page 115 for more information 

target 

The depot from which software is to be removed. If not specified, the 
target is assumed to be the system itself. 


Patch-related The following options have the most relevance to patching (see "Setting 
Options Default Values for Command Options" on page 117). Where appropriate, 

default values areshown. For thefull set of availableoptions, consult the 
swremove(lm) man page or refer to the SD-UX manual. 


Table B-6 Patch-related options for swremove 


option=default value 

Menu Path in Interactive Interface 

Description 


autoselect_reference_bundles=true 

None 

If true, bundles that have the is_reference attribute set to true will be automatically removed when 

the last of its contents is removed. If false, the bundles will not be automatically removed. 

enforce_dependencies=true 

Options^Change Options^Enforce 
dependency analysis errors in agent 


Enforces software dependencies. When software selected for removal has a registered dependency, 
if the dependency is not present on the target system or also selected for removal from the source 
depot, removal only proceeds if enforce_dependencies is set to false. 


While few patches currently exist with dependencies enforced by the SD-UX tools, those that do 
employ them to enforce critical requirements of content and removal order. Do not set this option to 
false unless directed to do so by an HP Support Engineer. 


enforce_scripts=true 

Options^Change Options^Enforce 
script failures 

Each patch has several removal scripts associated with it. These scripts control all aspects of the 
patch infrastructure and may issue errors to protect the system from incorrect patch usage. This 
option should not be used unless directed by an HP Support Engineer. 

mount_all_filesystems=true 

Options^Change Options^Mount 
filesystems in /etc/fstab or 
/etc/checklist 
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Table B-6 Patch-related options for swremove 


By default, SD-UX requires that all filesystems listed in the systems /etc/fstab file are mounted prior 
to removal. Setting this option to false removes this restriction. 


write_remote_files=false 


None (default cannot be changed within 
GUI) 


Prevents removal of files from a target that exists on a remote (NFS) file system. By default, 
swremove skips files that would be removed from an NFS file system. When set to true and 
superuser has write permission on the remote file system, files are removed from remote systems. 


Examples Remove only the bundle wrapper xsw800hwcri020 from the system, 

leaving any contents present (Note that the trailing period (.) is essential 
to removing the wrapper only): 

swremove XSW800HWCR1020. 

Remove all contents of the depot /depots/MyOepot: 
swremove -d \* @ /depots/MyDepot 


Appendix B 


107 







SD-UX Tools & Objects 

The swiist Command 


The swiist Command 

Theswlist(lm) command provides information on software installed on a 
system or located in a depot. You can: 

• See what's i nstal I ed on a system. 

• See what software is in a depot. 

• Check attributes of software. 

• See what depots are aval I able on remote systems. 

Synopsis swiist [-d] [-v] [-a attribute] [-1 level] [-s source] 

[software_selections] [ @ target ] 


Table B-7 Patch-related command line arguments for swiist 


-d 

Lists software depots instead of software currently installed on the 
target system. 

-V 

If no -a options are specified, then list all the attributes for an object, 
one attribute per line. The attributes are listed in the format: 

keyword value 

If one or more -a options are specihed, then list the selected attributes 
in the above format. 

-a attribute 

The named attribute is included in the listing when dehned at the 
specihed level. While this option may be specihed multiple times, the 
ordering of the arguments does not control the format of the list. 

-s source 

Specihes the software source to list. This is an alternative way to list a 
source depot. You can also specify the sources as target depots and list 
them using the -d option. 

software_selections 

One or more software specihcations. See “Software Specihcations” on 
page 115 for more information. 

target 

The depot to be listed. If not specihed, the target is assumed to be the 
system itself. 
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Table B-7 

-1 level 


Patch-related 

Options 


SD-UX Tools & Objects 

The swiist Command 


Patch-related command line arguments for swiist 

Specifies the level detail of the swiist output. Possible level values are; 

file 

Lists all files recorded in the IPD. The listing may be limited in scope 
by the software_selections specification. Each file is preceded by 
the product and fileset that is the registered owner of that file. A 
comment (marked by a leading # character) precedes each block giving 
the name, revision, and description of the product or fileset to be listed. 

fileset 

List all filesets recorded in the IPD (in product. fileset format) 
with the associated revision and description. A comment (marked by a 
leading # character) precedes each block giving the name, revision, and 
description of the product. 

product 

List all products with revision and description for each. 

bundle 

List all bundles with revision and description for each. 

depot 

List all registered depots on the target system. 
default (no level specified) 

When no level is specified, swiist displays all bundles within the depot 
followed by any products not contained within a bundle. As is the case 
with their respective levels, the bundles and products are listed with 
revision and one-line description. 


None. For the full set of available options, consult the swlist(lm) man 
page or refer to the SD-UX manual. 


Appendix B 


109 





Examples 


SD-UX Tools & Objects 

The swiist Command 

List all patches in the depot /var/MyOepot on the system grendei: 

swiist -d -1 product PH[CKNS][OLES]_\* \ 

@ grendei:/var/MyDepot 

List thefilesets modified by installed patch PHSS_8675: 
swiist -a ancestor PHSS_8675 

List all of the files delivered within patch PHCO_12140 after 
downloading that patch from the ITRC: 

swiist -d -1 file @ /tmp/PHCO_12140.depot 

Also see "Software Specifications" on page 115 for more examples. 
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The swreg Command 

The swreg command registers or unregisters an existing depot. When a 
depot is registered, it can be accessed from remote systems. 

Unregistration of a depot can be a convenient way to limit access during 
development. (Notethat unregistered depots are still available locally.) 

Synopsis 

swreg -1 depot [-u] [-v] [objects] 

Table B-8 

Patch-related Command Line Arguments for swreg 

-1 depot 

Perform operations on depots. (Other levels of SD-UX objects may be modified by 
swreg, they are not within the scope of this tutorial.) 

-u 

Causes swreg to unregister the specified objects instead of registering them. 

-V 

Requests verbose mode. This option affects only standard output and not the log 
files. 

objects 

Specifies the path to the object[s] to be registered or unregistered. 

Patch-reiated 

Options 

None. For the full set of available options, consult theswreg(lm) man 
page or refer to Managing HP-UX Software with SD-UX. 

Exampies 

Register the patch depot XSW800GR1020: 

swreg -1 depot /cdrom/XSW800GR1020 

Disable remote access by unregistering the depot XSW800GR1020 (local 
access is still enabled): 

swreg -u -1 depot /cdrom/XSW800GR1020 
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The swpackage command 

The swpackage command is primarily used to create depots from source 
files. This command also allows the transfer of software onto a tape or 
into a tape depot which can then be used as a software source. Either 
method can be used to transport the contents of a depot to another 
system for local access. The tape can be used in the absence of 
networking support, and the tape depot could be provided via ftp(l). 

Synopsis swpackage [-p] [-v[v]] [-s directory] [-x option=value] 

[software_selections] [@ target] 


Table B-9 Patch-related command-line arguments for swpackage 


-p 

Previews the package operation without performing the actual 
packaging. (Preview mode is not enabled by default.) 

-V 

Requests verbose mode. This option affects only standard output and 
not the log files. 

-s directory 

An existing directory depot (which already contains products) to be 
used as the source. 

-X option=value 

Sets the specified default option to the value given, overriding any other 
values for that option. Patch-related default options are specified below. 
See “Setting Default Values for Command Options” on page 117 for 
more information on setting defaults. 

software_selections 

One or more software specifications. See “Software Specifications” on 
page 115 for more information 

target 

If you are creating a distribution depot (directory), this operand defines 
the location of the directory. Without this operand, /var/spool/sw is used 
as the default depot directory. 

If you are creating a distribution tape, this operand names the device file 
on which to write the tar archive. The device file must exist so that 
swpackage can determine if the media is a DDS tape or a disk file. 
Without this operand, swpackage uses the device file /dev/swtape. 
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SD-UX Tools & Objects 

The swpackage command 


Patch-related The following options have the most relevance to patching (see "Setting 
Options Default Values for Command Options" on page 117). Where appropriate, 

default values areshown. For thefull set of availableoptions, consult the 
swpackage(lm) man page or refer to the SD-UX manual. 


option=default value 

Description 

compress_files=false 

Setting this option to true causes swpackage to compress files 
before packaging them. This creates smaller depots. 

laYOUt_version=l.0 

Specihes the POSIX layout version to which the SD-UX 
commands conform when writing distributions. Supported value 
is 0.8. Refer to the swpackage(lm) or SD-UX manual for more 
information. 

target_type=directory 

Dehnes the type of distribution to create. The recognized types 
are directory and tape. 


swpackage 

Examples 


Re-package the enti re contents of the depot /var/spool/sw onto the tape at 

/ dev/rmt/ Om: 

swpackage -s /var/spool/sw -x target_type=tape \ 

@ /dev/rmt/Om 
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The cleanup Command 

The cleanup command removes any patches for earlier releases from the 
Installed Product Database after updating to a newer version of HP-UX. 
It is also used to remove patches from a software depot if they have been 
superseded by patches available in the same depot. The cleanup utility 
also allows patches to be committed across the entire system. 

The cleanup command is not delivered with HP-UX, but as patch 
PHCO_12140. 

The cleanup command logs all information to /var/adm/cieanup.iog. 
Synopsis cleanup [-F]|[-t]|[-1]|[-d absolute_path_to_depot] 


Table B -10 Patch-related Command Line Arguments for cleanup 


default 

Removes all backups of patches that have been superseded and 
prompts for trimming of the log files. Removal of superseded 
patch save areas leaves enough data on the system to allow patch 
removal back one level but precludes removing a series of 
patches in which each supersedes the next. Some accounting 
information (less than IK) is left on the system to allow 
SD-UX-database synchronization should a superseding patch be 
removed from the system. 

-F 

Removes all backups of patches, not just those which have been 
superseded. This recovers the most disk space but eliminates the 
possibility of backing out any currently installed patch. You are 
prompted before any backup removal takes place. 

-i 

Determines which patches in the IPD have been overwritten by 
installations or updates. These patches are removed from the 

IPD upon confirmation so that they are no longer displayed in 
the output of the swlist command. 

-t 

Trims all the SD-UX log files in /var/adm/sw/sw* . log. 

These log files are be trimmed to their most recent five entries. 
There is no confirmation step when trimming the log files only. 

-d absolute_path_to_depot 

Determines which patches in the software depot have been 
superseded by newer patches also available from the depot. 

Upon confirmation from the user, these superseded patches will 
be removed from the software depot. 


114 


Appendix B 











SD-UX Tools & Objects 

Other Options and Aids to Using the SD-UX Commands 


Other Options and Aids to Using the SD-UX 
Commands 

Software Specifications 

When an SD-UX command can be supplied a software selection, the 
selection is comprised of one or more software specifications. A software 
specification is a unique identifier for an SD-UX software object. A 
software specification must name either a product or a bundle, and 
filesets can be specified only within a product. If you explicitly select a 
bundle, all products within the bundle are also selected. If you select a 
product, all filesets within that product are also selected. 

For patch operations, you usually only need to refer to a patch or bundle 
name. 

The software specification takes one of the following formats: 

product[.fileset][,version] 

bundle[.product[.fileset]][,version] 

where the version has the form: 

[r=revision][,a=arch][,v=vendor][,c=category] 

(The version may also havea i=iocation component that applies only to 
installed software and refers to software installed to a location other 
than the default product directory.) 

The software_spec attribute contains the full software specification for 
any bundle, product, or patch (see "Patch-related Object Attributes" on 
page 96). You can usetheswiist command to display this information. 
The following example shows how swiist can create a list of the software 
specifications for a patch at the fileset level. The software specification 
for the patch product appears in the output as a comment: 

swiist -1 fileset -a software_spec PHKL_16750 

# PHKL_16750 

PHKL_16750,1=/,r=B.10.00.00.AA,a=HP-UX_B.10.20_700, v=HP 

PHKL_16750.PHKL_16750 PHKL_16750.PHKL_16750,1=/,r=B.10.00.00.AA, 
a=HP-UX_B.10.20 _700,v=HP 
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Session Files 

Session files let you save your work from a command session. Each 
invocation of an SD-UX command defines a session. The invocation 
options, source information, software selections, and target hosts are 
saved before command execution actually commences. This lets you re- 
execute the command even if the session ends before proper completion. 
Each session is saved to the file $HOME/.sw/sessions/{ command} .last. 
This file is overwritten on each invocation. 

You can also save session information from interactive or command-line 
sessions. From an interactive session, you can save session information 
into a file at any time by selecting the Save Session or Save Session As 
option from the File menu. From a command-line session, you can save 
session information by executing swinstall or swcopy with the -c 
session_file option. 

A session file uses the same syntax as the defaults files (see "Setting 
Default Values for Command Options" on page 117). You can specify an 
absolute path for a session file. If you do not specify a directory, the 
default location for a session file is $home/ . sw/sessions/. 

To re-execute a saved session from an interactive session, use the Recall 
Session option from the File menu. To re-execute a session from a 
command-line, specify the session file as the argument for the -s 
session_file option of swinstall or swcopy. 

Notethat when you re-execute a session file, the values in the session file 
take precedence over values in the system defaults file. Likewise, any 
command line options or parameters that you specify when you invoke 
swinstall or swcopy take precedence over the values in the session file. 


NOTE Use of session files is not recommended with swremove because the 

session filecould includesoftwareselectionsthat you do not want 
included in the removal operation. 
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Setting Default Values for Command Options 

SD-UX commands have extensive options that alter command behavior. 
The default option values are listed within the file 
/usr/iib/sw/sys.defaults, a templatethat lists and explains each 
option, all possible values, and the resulting system behavior. These 
options are listed as comments that you can copy into the system 
defaults file (/var/adm/sw/defauits) or your personal defaults file 
($HOME/. sw. defaults). 

Values in these option files are specified using this syntax: 

[command.]option=value 

These rules govern the way the defaults work: 

• Option values in /usr/iib/sw/sys.defaults are hard-coded and 
are usable only as text to copy to other default files. 

• Option values in /var/adm/sw/defauits file affect all users in a 
system. 

• Option values in your personal $home/. sw/defauits file affect only 
you and not the entire system. 

• Option values in a session file affect activities only for that session 
and revert when that session is completed. 

• Option values changed on the command line affect only that activity. 

For system-wide policy setting, use the /var/adm/sw/defauits file. 
(Note that individual users can override these values with their own 
SHOME/. sw/defauits file, sesslon files, or command line changes.) 

System-wide option values can also be overridden by specifying an 
options file with the-x option_flie or with one or more-x 
option=vaiue options directly on the command line. Values can also be 
changed using the GUI Options Editor. 

Altering option values and storing them in a defaults file can help when 
you want the SD-U X command to behave the same way each ti me the 
command is invoked. Options in the defaults file are read as part of 
command initialization. Because the daemon is already running, after 
changing daemon options, the daemon must be restarted in order for 
these options to be recognized. To restart the daemon, type: 

/usr/sbin/swagentd -r 
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This appendix lists and explains the individual fields in the patch text 
file that accompanies each patch. 
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Patch Text File Fields 


Patch Text File Fields 

Patch Name 

The name of the patch. This identifier is used for: 

• Patch shar, text, and depot files 

• Patch products 

• H P-UX 10.x releases the patch fileset ***Huh? *** 

The identifier syntax is: 

PHxx_yyyy 

where: 

• PH =Patch HP-UX. 

• XX = area patched: 

CO general H P-UX commands 

KL kernel patches 

N E network specific patches 

SS SS =all other subsystems (Xll, Starbase, etc.) 

yyyy a unique number 

For example, PHSS_14014 identifies an HP-UX subsystem patch name. 

Patch Description 

A one-line description of the patch. 

Creation Date 

The date the patch was created. 

Post Date 

The date on which HP posted the patch for general distribution. 
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Patch Text File Fields 


Hardware Platforms—OS Releases 

The hardware platforms and HP-UX OS releases on which you can 
install the patch. 

Products 

The product name and all product revisions to which the patch applies, if 
the patch is for an optional product (that is, for a non-core operating 
system product). Ifthe patch is for the core operating system, the value 
in this field is "N/A". 

Filesets 

A list of all thefilesetsthat contain one or more files that are included in 
this patch. 

Automatic Reboot? 

A Yes/No flag that indicates whether or not this patch requires a system 
reboot after installation. 

Status 

The support status of the patch, either GR or SP, where: 

• GR = General Release 

A patch that should be installed on all systems meeting the OS, 
product, and dependency requirements. 

• SP =Special Release 

A site-specific patch for installation at one specific customer or set of 
customers, and other non-GR patches. 
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Patch Text File Fields 

Critical 

A Yes/No flag followed by text. The flag indicates a "critical" patch—a 
patch that fixes a critical problem or that supersedes a patch that fixes a 
critical problem. HP uses these criteria to define critical problems: 

• The problem causes the OS or kernel to fail, crash, or panic. 

• The problem causes a major application to fail in a way that severely 
impacts the system's operation. 

• The problem causes data loss or corruption. 

• The patch delivers a fix related to processing dates in the year 2000 
and beyond. 

Path Name 

The patch's storage location on the H P ITRC ftp server 

(ftp: //us-f f s. external. hp. com). The current choices for supported 

releases are: 

• /hp-ux_patches/s700/10.X/PHxx_yyyy 

• /hp-Tax_patches/s800/10. X/PHxx_yyyy 

• /hp-ux_patches/s700_800/10.X/PHxx_yyyy 
The identifier syntax is: 

PHxx_yyyY 

where: 

• PH =Patch HP-UX. 

• XX = area patched: 

CO general H P-UX commands 

KL kernel patches 

N E network specific patches 

SS SS =all other subsystems (Xll, Starbase, etc.) 

yyyy a unique number 

For example, PHSS_14014 identifies an HP-UX subsystem patch name. 
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Patch Text File Fields 


Symptoms 

The external symptoms of the problem (specific system behavior that a 
user would experience). 

Defect Description 

A detailed description of the defect that specifically addresses the 
conditions that caused the problem (if they are known), and (if known) 
how to reproduce the problem. Also includes methods to verify if the 
patch needs to be installed. 

SR 

A list of all Service Request (SR) numbers addressed by the patch and all 
its predecessors. An SR is a formal request from a customer to have a 
defect resolved or a feature added to H P software. 

Patch Files 

Thefull installed path name of all files in the patch. If the patch replaces 
an object module in a library, thefull path of the library is listed with the 
object module following in parentheses. For example, if a patch replaces 
the object module vers, o in the library /usr/conf/iib/iibhp-ux.a, 
the path listed would be /usr/conf/lib/libhp-ux.a (vers.o). 


what(l) Output 

The output (or "what string") from the what command for each file or 
library object file listed in the Patch Files field. For example: 

$Revision: 1.13 $. The what String lets you identify the Software 
version, which you can use to verify that a patch is installed. Seethe 
what(l) manpagefor more information on the what command. 

Patch Conflicts 

All known patch conflicts, including file conflicts and behavioral conflicts. 
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Patch Text File Fields 

Patch Dependencies 

A list of other patches that must be installed to insure proper operation 
of this patch. 

Hardware Dependencies 

Specific system models to which this patch is limited. 

Other Dependencies 

Any non-patch and non-hardware dependencies that may exist. 

Supersedes 

A list of all patches replaced by this patch. 

Equivalent Patches 

All equivalent patches for other hardware platforms and OS releases not 
including this patch. 

Patch Package Size 

The size in Kilobytes of the patch. 

Installation Instructions 

The standard installation instructions common to all patches. (See 
Chapter 5, "Patch I nstallation,"for more information on patch 
installation.) 

Special Installation Instructions 

Any special instructions not covered by other text fields. 
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